MCP is often introduced as the plumbing that lets a model call tools. That description is technically true and architecturally incomplete.
The moment an agent can inspect a repository, query a service, modify an artifact or execute a workflow, the integration becomes an operational boundary. The design problem starts to resemble API and security architecture more than prompt engineering.
Capability is the unit of design
Do not begin with “what can the agent connect to?” Begin with “what capability does this task require?”
A capability should be narrow enough that you can state:
- what the agent may read;
- what it may change;
- what inputs are accepted;
- what evidence comes back;
- what requires a separate approval step.
This reduces ambiguity for the model and makes the system easier to audit for humans.
Read and write paths should feel different
Inspection is cheap. Mutation is expensive.
A repository-aware agent may need broad read access to understand architecture while still having tightly scoped write actions. The same principle applies to infrastructure, databases and external APIs.
When a tool combines observation and mutation behind one vague action, you lose a useful safety boundary and make debugging harder.
Tool output is evidence
The output of a tool call should be treated as structured evidence that can be checked by a later stage of the workflow.
That means tool responses should be predictable enough to consume, log and compare. A validation agent should be able to inspect what happened without depending on the implementation agent’s prose summary.
The architecture rule
Design MCP tools the way you would design an internal production API: small surface, explicit semantics, least privilege and observable outcomes.
The model is new. The interface discipline is not.