Turning Tools into Pluggable Hands: MCP Solves the N×M Integration Problem — Without Falling into Security Traps

You already have a system that can "think": it breaks goals into steps and plans iteratively. The next practical question is—what does it use to perceive and act on the world? The answer is not a bigger model, but externalizing capabilities into tools, connected in a reusable, governable way. Otherwise you fall into the classic N×M integration hell: N models × M tools = N×M one-off glue code that gets more brittle with every addition.

This post focuses on two questions:

• How should tools be designed so the model uses them correctly, efficiently, and safely?
• How does MCP (Model Context Protocol) standardize tool integration—and what new enterprise risks and governance gaps does it introduce?

Key points

1. What counts as a "tool"?

A tool is not just any API—it's a contractual external capability. The model generates content and decisions; tools let the system learn new facts or execute external actions:

• Know something (retrieval): fetch data so the next reasoning step is grounded in facts.
• Do something (action): call APIs, run code, control devices, file tickets, send messages.

Example: a weather assistant needs tools to fetch location and live weather, and to perform unit conversion the model can't reliably do itself.

2. Three tool forms

• Function tools: explicitly defined with name, parameters, description; the tool definition is the contract between model and tool.
• Built-in tools: provided implicitly by the model service (e.g., URL context, code execution, search); definitions are hidden from the developer.
• Agent tools: one agent can be invoked as another agent's tool—delegate subtasks to a sub-agent, get structured results back. "Use experts as tools."

3. Tool design best practices

• Clear naming and complete parameter docs: create_critical_bug_in_jira_with_priority beats update_jira; descriptions should state what it does, when to use it, what it returns, and side effects.
• Describe actions, not implementations: system prompts should say *what to accomplish* ("create a bug record"), not *which tool to call*—tool sets change, especially with dynamic discovery.
• Publish tasks, not API calls: don't expose 100-parameter enterprise APIs. Wrap them into user-comprehensible tasks like create_ticket_with_summary_and_priority, add_comment_to_ticket, assign_ticket_to_oncall.
• Keep tools granular: single responsibility makes selection, docs, validation, and permissions easier.
• Design for concise output: write large results to external storage (temp tables, object storage, artifacts) and return only references; offer secondary retrieval tools for slices/summaries.
• Schema validation as a double safety net: input validation blocks bad args; output validation guarantees parseability.
• Actionable error messages: errors are fed back into model context—say why it failed (e.g., rate limit) and what to do next (retry in 15s, ask user for the product_id, search by name instead).

4. Why MCP: the N×M problem

Without a standard, every model/framework × tool/system pair needs a custom adapter. MCP's goal: turn tool integration from "custom glue" into "pluggable interfaces."

5. MCP architecture and communication

• Host: your app/agent—UX, orchestration, security policy, guardrails.
• Client: embedded in the host; maintains the connection and session lifecycle.
• Server: publishes capabilities, handles tool discovery (tools/list), executes requests; in enterprises also carries security and governance duties.

Communication uses JSON-RPC 2.0 with Request / Result / Error / Notification messages over two transports: stdio (local subprocess, e.g., filesystem access) and Streamable HTTP (recommended for remote, streaming, stateless-friendly).

6. Primitives: Tools, results, errors

Tool definitions include name, title, description, inputSchema, outputSchema (treat as mandatory), and annotations (readOnly, idempotent, destructive, openWorld).

> Annotations are not a security boundary—even from trusted servers, they're hints and can't be relied on for access control.

Results may be unstructured (Text/Image/Audio), structured JSON (validate against outputSchema), or resource references (dangerous from untrusted servers). Errors flow via two channels: JSON-RPC protocol errors and tool results with isError: true—both should be actionable.

7. The costs of autonomy

MCP's benefits—dynamic tool discovery, standardized interfaces, a reusable ecosystem, flexible architecture, governance mounting points—come with costs:

• Context window bloat: tool definitions and schemas eat tokens, raising cost and latency.
• Degraded reasoning: too many tools means more mis-selection.
• Stateful connections complicate horizontal scaling and load balancing.

A proposed evolution (e.g., RAG-MCP, arXiv:2505.03275) treats tool discovery as a retrieval problem—retrieve a few relevant tools instead of loading all definitions—but a poisoned index becomes a new injection surface.

8. Enterprise threat model and mitigations

• Dynamic capability injection: a server can silently change its tool list or semantics. *Mitigate with* explicit allowlists, change-verification, version/hash pinning, gateway filtering of tools/list, and hosting servers in controlled environments.
• Tool shadowing: malicious tools with aggressive descriptions hijack legitimate calls. *Mitigate with* semantic collision detection (LLM-based, not just string matching), mTLS, deterministic policy enforcement at lifecycle points, human-in-the-loop for high-risk actions, and restricting agents to approved servers.
• Malicious tool definitions/contents: descriptions can manipulate the planner; returned content can carry injected instructions or leak sensitive data back through the model. *Mitigate with* input validation (path traversal, injection), output sanitization (tokens, PII, URLs, executable HTML/Markdown), trusted/untrusted dual planners, allowlisted resource URLs with explicit consent, and sanitizing tool descriptions at the gateway.
• Sensitive information leaks: conversation context is often passed wholesale to tools; Elicitation lets servers solicit more data. *Mitigate with* structured outputs, sensitive-field tagging, and taint tracking—mark user free text and external data as tainted; treat outbound sends and public writes as sensitive sinks requiring extra approval.
• No native scoped access: coarse protocol-level authorization and ambiguous identity. *Mitigate with* audience validation and scoped, short-lived credentials bound to the caller, least privilege, and never putting secrets in model context—credentials stay client-side and travel over a side channel.

9. A recommended enterprise deployment pattern

Don't run raw open-protocol MCP against core systems. Instead:

• Host/Agent app: orchestration and UX only.
• Hardened MCP client: allowlists, schema validation, sensitive-data interception, HIL.
• Agent/API gateway: centralized policy—tools/list filtering, identity, mTLS, rate limits, audit logs.
• Controlled MCP servers: hosted in managed environments with reviewed tools.
• Observability: MCP itself provides no standard tracing/logging/metrics—you must add it externally.

> Tip: treat MCP as the "USB port" and the gateway as the enterprise's power-management chip. USB standardizes the shape; voltage, current, and overload protection must be handled by higher layers.

References

1. Model Context Protocol — https://modelcontextprotocol.io/ 2. MCP Specification (2025-06-18) — https://modelcontextprotocol.io/specification/2025-06-18/ 3. Gan & Sun (2025), *RAG-MCP* — https://arxiv.org/abs/2505.03275 4. Hou et al. (2025), *MCP: Landscape, Security Threats, and Future Research Directions* — https://arxiv.org/abs/2503.23278 5. Google Cloud, *Model Armor overview* — https://cloud.google.com/security-command-center/docs/model-armor-overview