Most discussions around MCP focus on tool calling.
That is natural.
When people first see MCP, the obvious use case is simple:
Let the AI call external tools.
A model can read a GitHub issue.
A model can query a database.
A model can update a file.
A model can call an API.
In that sense, MCP looks like an RPC layer for AI agents.
That is useful.
But I think it may not be the most important use of MCP.
The more interesting use is this:
MCP can distribute context, rules, skills, and operating contracts to AI clients.
In other words, MCP is not only a way for AI to call tools during work.
It can also be a way to define the working environment before the work starts.
The problem with RAG
RAG is usually used to answer this question:
What information might be relevant to this request?
The system searches documents, retrieves chunks, and gives them to the model.
This works well for many cases.
But it has structural limits.
RAG retrieves likely relevant information.
It does not necessarily define how the work should be done.
For team-level AI work, this is a problem.
A team does not only need information.
A team also needs shared rules.
For example:
- What is the authoritative source?
- What should be treated as unknown?
- When should the AI stop?
- When is human confirmation required?
- What is the closure condition?
- Which workflow should be used?
- Which domain skill applies?
- What evidence must be recorded?
RAG can retrieve documents that describe these rules.
But retrieval is not the same as governance.
A retrieved chunk is just context.
It is not necessarily an operating contract.
The problem with local prompts
Many teams try to solve this with prompts.
They write instructions like:
Follow our coding rules.
Use this design document.
Ask questions when unclear.
Do not make risky changes.
This helps, but it does not scale well.
Each developer may have a different local prompt.
Each AI client may load a different file.
Each repository may contain a slightly different version of the rules.
Some people may forget to update their instructions.
Some people may not load the correct context at all.
As a result, the quality of AI output depends too much on the individual user.
One developer gets good output because they know how to explain the domain.
Another developer gets poor output because they do not know which context matters.
That is not a team-level system.
That is individual prompt craftsmanship.
A different way to use MCP
What if MCP is used not only for tool calls, but also for startup context?
At session start, the AI client calls a startup function.
That function returns:
- access policy
- authoritative context source
- available skills
- workflow catalog
- unknown handling rules
- closure rules
- tool contracts
- document resolvers
Now the model does not merely have access to tools.
It starts inside a governed context.
This changes the role of MCP.
RPC-style MCP:
The model calls tools during work.
Context-distribution MCP:
The model receives the rules of work before work starts.
That difference is important.
Why startup context matters
If an MCP server exists, that does not mean the model will use it.
The model has to know that MCP is not optional background infrastructure.
It has to know that MCP is the authoritative source for the session.
This requires a client-side bootstrapping rule.
For example:
At session start, if the project MCP server is configured, call
get_startup_contextfirst and treat the returned access policy as authoritative.
This is a small rule, but it changes the behavior of the system.
Without it, the AI may try to answer from memory, local files, or partial context.
With it, the AI first asks the MCP server how the work should be governed.
That is the difference between “MCP is available” and “MCP controls the working context.”
From knowledge retrieval to skill distribution
This also changes how domain knowledge can be distributed.
In many organizations, domain knowledge is held by experienced people.
They know:
- which documents matter
- which rules are obsolete
- which terms have special meaning
- which changes are risky
- which assumptions are forbidden
- which checks are required before completion
If this knowledge is only written as documentation, every user must read and understand it.
If this knowledge is embedded into prompts, every user must keep their prompt updated.
But if this knowledge is packaged as MCP-accessible skills, the distribution model changes.
The skill author maintains the domain skill centrally.
The users consume it through MCP.
The AI client receives the same skill definition at runtime.
This separates two roles:
- the people who define the skill
- the people who use the skill
That separation matters.
It means a senior engineer can define a domain-specific skill once.
Then multiple developers can use that same skill through their AI clients.
The goal is not only better answers.
The goal is more consistent output across the team.
Local checkout should not be required
Another advantage is portability.
If every user needs a local checkout of the governance repository, the system becomes fragile.
Local copies become stale.
Different users may have different versions.
Setup becomes heavier.
Onboarding becomes slower.
Updates are harder to propagate.
With MCP-based context distribution, the local client does not need the full governance repository.
The local client only needs a bootstrapping instruction and MCP access.
The authoritative definitions stay on the MCP server.
The AI resolves documents, skills, workflows, and contracts through named MCP tools.
This makes the governance layer portable.
The user does not carry the entire context system locally.
The user connects to it.
RAG vs MCP context distribution
The difference can be summarized like this.
RAG answers:
What information might be relevant?
MCP context distribution answers:
What context and rules must govern this work?
RAG retrieves knowledge fragments.
MCP can expose authoritative context.
RAG is useful for answering questions.
MCP can be useful for controlling work.
RAG is often probabilistic retrieval.
MCP can provide named resolvers, catalogs, policies, and contracts.
RAG can tell the model something.
MCP can tell the model how it is allowed to proceed.
This is why I think MCP as context distribution may be more important than MCP as RPC.
Unknowns should be part of the runtime
One example is unknown handling.
In normal AI usage, uncertainty often disappears into fluent text.
The model may say something plausible.
The user may not notice that an important assumption was unresolved.
For serious work, unknowns should not be hidden.
An unknown should be a first-class runtime signal.
For example:
- the model does not know a required fact
- the model does not understand a requirement
- the model lacks a domain rule
- the model cannot verify an assumption
- the model needs human confirmation before proceeding
If unknown handling is only a prompt instruction, it is weak.
But if unknown handling is part of the MCP-distributed operating contract, every skill and workflow can share the same rule.
The model can be required to record unknowns.
Closure can be blocked when unresolved unknowns remain.
Risky changes can require escalation.
This is not ordinary retrieval.
This is governance.
MCP as an operating layer for AI work
I now see MCP as something broader than a tool-calling protocol.
It can become an operating layer for AI-assisted work.
Not an operating system in the traditional sense, but a layer that defines:
- what context is authoritative
- which skills are available
- which workflows apply
- how uncertainty is handled
- when work must stop
- how closure is judged
- what evidence must be recorded
That is much more than RPC.
RPC lets the model do things.
Context distribution tells the model how to work.
For individual experiments, this may not matter much.
For teams, it matters a lot.
Because teams do not only need powerful AI.
They need repeatable AI-assisted work.
The key idea
The key idea is simple:
Do not only give AI tools.
Give AI a governed working context.
MCP makes this possible because it can expose not only actions, but also resources, prompts, catalogs, resolvers, and contracts.
This suggests a different direction for MCP-based systems.
Instead of asking:
What tools can the AI call?
We should also ask:
What context must the AI load before it starts?
What rules must govern the work?
What skills should be distributed to every user?
What should prevent unsafe or incomplete closure?
This may be where MCP becomes most valuable.
Not as an RPC layer for agents.
But as a portable context distribution layer for team-level AI work.
Top comments (5)
I like the context distribution framing. Tool calling gets most of the attention, but the durable value may be giving agents access to the right rules, workflows, schemas, and project memory at the right stage instead of stuffing everything into the initial prompt.
Thanks — that is exactly the point I wanted to emphasize.
Tool calling is useful, but it makes MCP look like RPC. I think the deeper value is staged context delivery: rules, workflows, schemas, and project memory become available when they are relevant, instead of being stuffed into the initial prompt.
I wrote about the bootstrapping side here:
dev.to/synthaicode_commander/claud...
And the boundary side here:
dev.to/synthaicode_commander/only-...
That shifts the design question from “what can the agent call?” to “what context should the agent receive at each stage?”
That staged context idea is the part I keep coming back to. If everything is dumped into the initial prompt, the agent has to carry dead weight and decide which rule matters from memory. If the context is staged, a skill or MCP server can act more like a just-in-time operating manual: load the right constraints at the moment the action becomes possible.
The distinction holds, but in practice the two modes need to coexist within the same session. At startup, context-distribution MCP works well for rules, constraints, and operating contracts -- those are stable enough to load once. But domain knowledge that can change mid-session (live system state, data written earlier in the conversation, external API state) needs on-demand tool calls, because startup context goes stale. The pattern that worked for me was a lightweight startup payload for invariants only, and a lazy-loaded tool registry for anything that can change. Mixing both in the same startup function doesn't work well because the client can't distinguish what needs refreshing mid-session.
Thanks, I agree with this distinction.
I do not think context-distribution MCP should replace on-demand tool calls. They need to coexist in the same session.
The way I see it is:
So the startup payload should not be a large knowledge dump. It should be a lightweight boot contract that tells the client how the session is governed and where to resolve context when needed.
That also means the startup function should probably distinguish between:
I think this is where MCP becomes interesting: not as a replacement for RPC, but as the layer that tells the AI which context is authoritative, which context is stable, and which context must be fetched on demand.