In my previous post, I wrote that MCP may be more useful as a context distribution layer than as a simple RPC mechanism.
The discussion that followed made the idea clearer.
The real point is not “how to use MCP.”
The real point is:
How should we give context to AI systems in stages?
MCP is useful because it gives us a clean transport for that staged context.
It can expose documents.
It can expose resolvers.
It can expose workflows.
It can expose skills.
It can expose operating contracts.
That means MCP is not only a tool-calling interface.
It can become a pluggable context layer for AI-assisted work.
Many AI coding setups rely on local instruction files.
Examples include:
At first, this works well.
You write a few rules.
Then you add coding conventions.
Then architectural constraints.
Then domain knowledge.
Then workflow notes.
Then testing rules.
Then risk warnings.
Then things the AI should never do.
Then things the AI should always check.
Eventually, the instruction file becomes too large.
Then a new ritual begins:
compress the context so the AI can use it.
This becomes part of the daily cost of using AI.
People maintain prompts.
People compress documents.
People remove old rules.
People rewrite context.
People tune instructions for each client.
The result is fragile.
The AI output depends on how well each user maintains their local context.
That is not a scalable team system.
I think AGENTS.md should have a smaller role.
AGENTS.md should not contain all domain knowledge.
It should not contain every workflow.
It should not contain every skill.
It should not become a compressed version of the organization.
Instead:
AGENTS.md should be a boot.
Its job should be simple:
That is all.
The detailed knowledge should live elsewhere.
The startup file should point to the context system.
It should not become the context system.
Once context is provided through MCP, the architecture changes.
Before MCP:
The user carries the context locally.
After MCP:
The MCP server provides the context.
This is a big difference.
A user no longer needs a full local checkout of the governance repository.
A user no longer needs to maintain a giant prompt.
A user no longer needs to manually copy the latest domain rules.
The client only needs:
The context itself becomes pluggable.
Project A can use one MCP context server.
Project B can use another.
A domain team can provide its own skill catalog.
A governance team can maintain shared operating contracts.
The AI client becomes lighter.
The domain context becomes centrally maintained.
When people think about giving context to AI, they often imagine sending everything at once.
All documents.
All rules.
All constraints.
All domain knowledge.
All examples.
All workflows.
This creates a new problem.
The context becomes too large.
Important rules become diluted.
The model receives information that is not needed for the current task.
Stable rules and volatile state get mixed together.
The AI may follow the wrong document, the wrong workflow, or the wrong level of detail.
More context does not always mean better output.
Sometimes, too much context makes the AI less reliable.
This is why context should not be delivered as a single dump.
It should be delivered as structured packages.
For example: Each package should have a clear purpose.
Startup context should only contain invariants.
A Skill should contain the knowledge and procedure for one kind of work.
A workflow should define the expected sequence of work.
A resolver should fetch authoritative documents when needed.
Runtime tools should fetch volatile state only when needed.
This keeps the model focused.
The AI does not need the entire organization in its context window.
It needs the right context at the right stage of work.
This is where MCP becomes useful.
MCP gives us named entry points for context.
Instead of pushing one huge prompt into the model, the client can ask for:
That makes context staged, explicit, and easier to reason about.
The goal is not to maximize context size.
The goal is to control context shape.
If MCP can deliver documents, it can deliver more than documents. A document is context.
A Skill is also context, but with a stronger structure.
A good Skill does not only say:
Here is some information.
A good Skill says:
Here is how this work should be done.
A domain Skill can include:
This is much more valuable than simply retrieving document chunks.
If documents distribute knowledge, Skills distribute work quality. That is the key point.
Many AI Skills today are command-oriented.
They are useful, but they are often too low-level.
For example: This looks like automation.
But in practice, it often becomes micromanagement.
The human still has to decide:
The AI executes small operations.
The human manages the workflow.
That does not create a large productivity gain.
It only changes the interface.
The user is still steering every step.
The hard part of professional work is not always execution.
The hard part is judgment.
For software work, the important questions are often: Generic command bundles do not answer these questions.
They automate operations, not judgment.
That is why command-level Skills can improve convenience without improving team-level output quality.
They reduce keystrokes.
They do not necessarily reduce variance.
A better Skill boundary is not a command.
A better Skill boundary is a business-level work unit.
Examples:
These are not single commands.
They are units of work.
But there is an important point here:
Domain knowledge alone is not enough.
A repository may contain many documents.
A team may have many rules.
A project may have many constraints.
An organization may have a large amount of accumulated knowledge.
But giving all of that knowledge to the model does not automatically improve the work.
The model does not need all domain knowledge.
It needs the knowledge that is necessary for the current work.
And it needs that knowledge at the right moment.
That is why a domain Skill should not only contain instructions.
A domain Skill should define:
In other words, a Skill is not just a procedure.
A Skill is a work unit with controlled access to domain knowledge.
This is where MCP becomes useful as a context distribution layer.
The Skill does not need to embed every document directly.
The startup context does not need to preload the entire domain.
The client does not need to maintain a giant local prompt.
Instead, MCP can provide the Skill and the knowledge access path.
The AI can load:
This makes domain knowledge usable.
The value is not in storing knowledge.
The value is in delivering the right knowledge for the right work unit.
A senior engineer can define the Skill.
The Skill can point to the required domain knowledge.
The team can use the Skill through MCP.
The AI can follow the same rules each time.
The output becomes more consistent because the work unit, the knowledge access path, and the closure criteria are distributed together.
That is why domain Skills should be business-level units.
They are not command bundles.
They are packaged work contexts.
If Skills are business-level units, users should not have to manually pick every command. The user should describe the work intent.
The system should route that intent to the right Skill.
That is why semantic routing matters.
Command routing says:
Which tool should I call?
Semantic routing says:
What kind of work is this?
That difference matters.
If the user must manually choose every command, the workflow stays at the micromanagement level.
If the system can route work intent to a domain Skill, the user can delegate at a higher level.
The Skill then carries the domain rules, references, unknown handling, and closure criteria.
This is closer to real delegation.
With MCP and semantic routing together, the model becomes different.
The user does not maintain a giant local prompt.
The user does not manually select every low-level command.
The user does not need a local copy of every governance document.
Instead:
This is not just tool calling.
This is staged context delivery.
This is the layer that has been missing.
Individual AI use depends on personal prompt skill.
Generic Skills automate commands.
RAG retrieves likely relevant knowledge.
RPC lets the AI call tools.
But teams need something else.
Teams need a way to distribute:
That is what domain Skills can provide.
And MCP makes those Skills pluggable.
The main idea is simple:
AGENTS.md should be a boot, not a knowledge base.
And:
MCP should make domain context and domain Skills pluggable.
This avoids the old pattern where every user maintains a growing local prompt.
It also avoids the trap of treating Skills as command bundles.
For team-level AI work, the goal is not to automate more commands. The goal is to reduce quality variance.
Generic Skills automate operations.
Domain Skills distribute judgment.
That is why I think MCP becomes most valuable when used for staged context delivery and domain Skill distribution.
Not just RPC.
Not just RAG.
Not agent-to-agent coordination. A pluggable context layer for consistent AI-assisted work.