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.
The old pattern: local instruction files grow forever
Many AI coding setups rely on local instruction files.
Examples include:
- AGENTS.md
- CLAUDE.md
- custom instructions
- project prompts
- local rule files
- compressed context summaries
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.
AGENTS.md should not become the knowledge base
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 bootloader.
Its job should be simple:
- tell the AI client where the project context lives
- tell the AI client which MCP server to use
- tell the AI client what to load at startup
- tell the AI client which source is authoritative
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.
MCP makes context pluggable
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:
- access to the MCP server
- a startup rule that tells the AI to load context from MCP
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.
Context should be delivered as packages, not dumps
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:
- startup context
- skill catalog
- workflow definition
- domain rule set
- authoritative document reference
- resolver policy
- closure contract
- runtime state fetched on demand
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:
- the startup contract
- the relevant Skill
- the required document
- the closure rule
- the current runtime state
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.
Documents imply Skills
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:
- domain knowledge
- terminology
- authoritative references
- workflow steps
- decision criteria
- risk conditions
- unknown handling
- escalation rules
- closure conditions
- required evidence
This is much more valuable than simply retrieving document chunks.
If documents distribute knowledge, Skills distribute work quality.
That is the key point.
Generic command Skills are not enough
Many AI Skills today are command-oriented.
They are useful, but they are often too low-level.
For example:
- run this command
- inspect this file
- generate this diff
- execute this test
- summarize this output
- call this API
This looks like automation.
But in practice, it often becomes micromanagement.
The human still has to decide:
- which command to run
- when to run it
- what result matters
- whether the result is enough
- whether the AI should continue
- whether the task is complete
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 problem is not command execution
The hard part of professional work is not always execution.
The hard part is judgment.
For software work, the important questions are often:
- Is this change compatible with the existing design?
- Is this requirement fully understood?
- Which documents are authoritative?
- What is still unknown?
- Is the impact analysis complete?
- Should this risk be escalated?
- What evidence is required before closure?
- Is it safe to proceed?
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.
Domain Skills should be business-level units
A better Skill boundary is not a command.
A better Skill boundary is a business-level work unit.
Examples:
- analyze change impact
- validate a design against known constraints
- classify unknowns
- review release readiness
- check requirement consistency
- evaluate whether closure is allowed
- investigate a domain-specific failure mode
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:
- what kind of work it handles
- which domain knowledge is required
- which references are authoritative
- which documents should be loaded first
- which documents should be resolved only when needed
- which assumptions are forbidden
- which unknowns must stop the work
- which evidence is required before closure
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:
- the relevant Skill
- the required domain rule set
- the authoritative document
- the resolver for linked references
- the closure contract
- the runtime state, only when needed
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.
Why semantic routing matters
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.
MCP + semantic routing changes the model
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:
- AGENTS.md bootstraps the AI client.
- The AI loads startup context from MCP.
- The startup context defines the operating contract.
- The user describes the work intent.
- Semantic routing selects the relevant domain Skill.
- The Skill loads the required context in stages.
- Runtime tools fetch volatile state only when needed.
- Closure rules decide whether the work can be completed.
This is not just tool calling.
This is staged context delivery.
The missing layer
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:
- domain judgment
- operating rules
- workflow boundaries
- evidence requirements
- stop conditions
- closure criteria
That is what domain Skills can provide.
And MCP makes those Skills pluggable.
The main idea
The main idea is simple:
AGENTS.md should be a bootloader, 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.