MCP Fundamentals For Agent Tooling
The value of MCP is not the transport format by itself. The value is that it forces you to distinguish capabilities that too many agent systems blur together.
Those capabilities are:
- Actions the model may request.
- Context the application may attach.
- Workflows the user may invoke.
That separation sounds abstract until you build a messy agent. Then it becomes the difference between a controlled system and a prompt-shaped shell script.
Tools
Tools are actions the model can request. They are the most dangerous primitive because they turn language into side effects.
A good tool is narrow, named clearly, and has a schema that constrains ambiguity. A bad tool is a general-purpose escape hatch like run_anything or exec_sql with no meaningful boundaries.
Tool descriptions matter. The model chooses tools based on those descriptions, so vague wording becomes runtime behavior.
That is the part people underestimate: naming and schema are not documentation polish. They are control surfaces.
Resources
Resources are application-provided context. They are not actions and should not pretend to be actions.
Use resources when the application already knows what context is relevant. This keeps retrieval policy with the client instead of forcing the model to discover everything by tool call.
Prompts
Prompts are reusable workflows, not secret incantations. They are part of the product surface.
The best prompts encode repeatable work patterns: review this diff, summarize this incident, classify this ticket, plan this migration.
Client Design
The client decides what servers are available, which tools are enabled, and which resources are attached. That makes the client an important security boundary.
Do not expose every tool to every workflow. A documentation assistant may need read-only search. A deployment assistant needs identity, approvals, and auditable side effects.
The client is where least privilege should become real.
The Design Rule
Use the least powerful primitive that solves the problem:
- Static context? Use a resource.
- Repeatable workflow? Use a prompt.
- External side effect? Use a tool.
This keeps the system easier to reason about. If you use a tool when a resource would do, you handed a choice to the model that the application could have made safely itself.
Common Mistakes
The first mistake is using tools for everything. That makes the model responsible for fetching context the application already knows it should attach.
The second mistake is exposing tools that are too broad. A run_query tool might be fine for analytics, but a run_anything tool is an operational risk.
The third mistake is ignoring identity. Tool calls should carry enough identity and audit context to answer: who asked, what was called, and why was it allowed?
MCP is not just a connector format. Used well, it is a discipline for drawing cleaner boundaries between the model, the application, and the user.