Making Tools into 'Pluggable Hands': Solving the N×M Integration Problem with MCP Without Falling Into Security Traps

Once you have a system that can "think"—decomposing goals into steps and planning in loops—the next practical question is: what does it rely on to see and act on the world? The answer is not a bigger model, but externalizing capabilities into tools, connected in a reusable, governable way. Otherwise every new model and new system drags you into the classic N×M integration hell: N models × M tools = N×M one-off glue code, increasingly brittle and tangled.

This article focuses on two things:

• 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 does it introduce? How do you add governance and defenses?

---

🧰 Chapter 1: What Counts as a "Tool"? Don't Hand the Model Raw APIs

In LLM applications, a "tool" is not just any API; it is a contractualized external capability: the model generates content and decisions, while tools let the system know new facts or execute external actions.

Tools fall into two broad categories:

• Know something (data/retrieval): fetch information from structured or unstructured sources so the next round of reasoning is grounded in facts.
• Do something (execution/actions): act on the user's behalf—call external APIs, run code, control devices, create tickets, send messages.

A typical example is a "weather assistant": the model itself doesn't know your location or real-time weather, and unit conversions aren't always reliable. The right approach: use tools to get location and weather data, use tools for conversion, and feed results back to the model to compose the answer.

> Tip: The essence of a tool is landing uncertain language onto a deterministic execution surface. > Models excel at expression and reasoning, but not real-time facts and precise actions. Tools take a system from "can talk" to "can act."

---

🧩 Chapter 2: Three Forms of Tools—Function, Built-in, and Agent Tools

🔧 Function Tools

You explicitly define functions with a name, parameters, and description; the model invokes them as needed. The tool definition is the contract between model and tool; in some frameworks, descriptions can be extracted from code comments/docstrings.

🧱 Built-in Tools

Some model services package tools as "built-in capabilities"—you just declare that you want them enabled, and the tool definitions are hidden server-side (e.g., URL context, code execution, search).

🧑‍🤝‍🧑 Agent Tools

An agent can be exposed as a tool to another agent: the main agent doesn't hand over full conversation control, but delegates subtasks to a sub-agent and gets structured results back. This is a key technique for engineering multi-agent systems: "use experts as tools."

---

🧠 Chapter 3: Tool Design Best Practices—Documentation Written for the Model Matters More

A tool's "documentation" isn't decoration—it goes into the model's context and directly affects tool selection and parameter generation.

📝 3.1 Clear Naming and Complete Parameter Descriptions

• Names should be specific, readable, and task-reflecting: create_critical_bug_in_jira_with_priority is more controllable and auditable than update_jira.
• Document input/output types and semantics; keep parameter lists short with intuitive names.
• Avoid jargon and implementation details; explain what it does, when to use it, what it returns, and what side effects it has.

🎯 3.2 Describe Actions, Not Implementations—Don't Hardcode Tools in System Instructions

System instructions should say *what to do*, not *which tool to call*. Tool sets may change (especially with dynamic discovery); hardcoding tool names creates conflicts or confusion.
• ✅ "Create a bug record for this issue"
• ❌ "Call the create_bug tool"

Also avoid duplicating tool docs (duplication introduces inconsistency), and don't force fixed workflows—let the model choose tool combinations autonomously within the goal.

✅ 3.3 Publish Tasks, Not API Calls

The most common mistake: exposing a complex enterprise API's parameter surface to the model. Enterprise APIs often have dozens or hundreds of parameters—designed for human developers with global context, not models making runtime decisions.

Instead, wrap tools as user-comprehensible tasks exposing only the minimal necessary fields. Don't expose a generic update_ticket; provide:

• create_ticket_with_summary_and_priority
• add_comment_to_ticket
• assign_ticket_to_oncall

🧱 3.4 Keep Tools Granular; Avoid Monolithic Multi-Step Tools

Single responsibility makes it easier for the model to decide when to call, and easier for you to document, validate, and control permissions. Occasionally wrapping a common long workflow into one tool improves efficiency, but internal actions and side effects must be documented very clearly.

🧾 3.5 Design for Concise Output—Don't Drown the Context Window

Large tables, big JSON, file contents, or base64 images returned by tools quickly consume context, raising cost and latency and polluting conversation history.

Recommended pattern:

• Write large results to external storage (temp tables / object storage / artifact services); the tool returns only a reference (table name / URI / handle).
• Provide secondary retrieval tools to pull small snippets or summaries on demand.

✅ 3.6 Use Schema Validation as a Double Safeguard

Input/output schemas serve as extra documentation *and* runtime guardrails:
• Input validation blocks bad params and out-of-range values.
• Output validation guarantees the caller can parse results and helps the model understand structure.

🧯 3.7 Error Messages Must Be Actionable—They're Instructions for the Model's Next Step

Returning only an error code is a wasted opportunity. Tool errors get fed back into the model's context, so they should say:
• Why it failed (e.g., rate limit)
• What to do next (wait 15 seconds and retry, ask the user to confirm the product_id, search by name instead)

---

🌐 Chapter 4: Why MCP—The N×M Integration Problem and a Tool Ecosystem

As tool integration scales, you hit N×M: N models/agent frameworks × M tools/systems/data sources, each pair needing its own adapter.

MCP's goal is to standardize this: turning tool connections from "custom glue" into "pluggable interfaces."

---

🏗️ Chapter 5: MCP's Core Architecture—Host / Client / Server

MCP is a client-server protocol architecture:

• Host: your application/agent host—responsible for UX, orchestrating tools, enforcing security policies and content guardrails.
• Client: embedded in the Host, maintains connections to MCP servers and manages session lifecycles.
• Server: exposes capabilities—tool discovery (tools/list), executes requests, formats and returns results; in enterprises it also carries security, scalability, and governance responsibilities.

The value of this three-part design: decoupling "agent logic" from "tool integration," fostering a reusable ecosystem.

---

📡 Chapter 6: Communication Layer—JSON-RPC + Two Transports

• Message format: JSON-RPC 2.0
• Message types: Request / Result / Error / Notification
• Transports:
• stdio: local subprocess communication, suitable for accessing local filesystems
• Streamable HTTP: recommended for remote communication; supports streaming responses and stateless server implementations

---

🧱 Chapter 7: Key Primitives—Tools Are the Star, But Don't Ignore Other Capabilities' Risks

MCP defines several capability types. In practice Tools are the most common; others (Resources, Prompts, Sampling, Elicitation, Roots) have limited support but notable risks.

🛠️ Tools: Standardized Tool Definitions

Tool definitions include:
• name (unique identifier)
• title (optional display name; recommended to always set)
• description (must be readable by humans and models)
• inputSchema (JSON schema for parameters)
• outputSchema (recommended to treat as required)
• annotations (behavioral hints: readOnly, idempotent, destructive, openWorld, etc.—but only *hints*, not trustworthy)

> Tip: annotations are not a security boundary. > Even from a trusted server, hint fields don't guarantee truth; clients must not use them as the basis for access control.

📦 Tool Results

• Unstructured: Text / Image / Audio (often base64 + MIME)
• Structured: JSON objects (strongly pair with outputSchema and validate)
• Resources: return links or embedded resources (fetching resources from untrusted servers is dangerous)

🧯 Error Handling: Two Channels

• JSON-RPC protocol-level errors (unknown tool, invalid args)
• isError: true in tool results (business/backend errors)

Error messages should be actionable, guiding the model on how to recover.

---

🧨 Chapter 8: MCP's Advantages and Costs—"More Autonomous" Comes with "More Dangerous"

🚀 Advantages

• Dynamic tool discovery: runtime tools/list, extensible capabilities
• Standardized interface: unified descriptions, schemas, result structures
• Ecosystem and reuse: registries/marketplaces emerge; tools can be shared
• Flexible architecture: models, tools, and memory are easier to swap and evolve
• An anchor point for governance: even with weak native security, there are places to insert policies and gateways

🐢 Costs: Performance and Scalability Challenges

• Context window bloat: tool definitions and schemas must enter context; more tools means cost, latency, and crowding out key information
• Degraded reasoning quality: too many tools makes mis-selection and drift more likely
• Stateful connection complexity: remote persistent connections combined with stateless REST ecosystems complicate horizontal scaling and load balancing

One proposed evolution: turn "tool discovery" into a retrieval problem—retrieve the few most relevant tools from a large library, then put only those definitions into context. But this adds a new attack surface: a poisoned retrieval index could inject malicious schemas.

---

🛡️ Chapter 9: Enterprise Security—MCP's New Threat Map and Countermeasures

MCP simplifies tool integration—and spreads risk faster. It is both a new API surface and a standardized "capability injection channel."

🧪 9.1 Dynamic Capability Injection

Risk: a server can change its tool list or semantics without your knowledge. A read-only service suddenly gains "purchase/transfer/delete" capabilities, instantly turning a low-risk agent high-risk.

Mitigations:

• Explicit allowlists in the client/SDK: only approved servers and tools
• Change-notification and re-validation (manifest changes trigger re-verification)
• Version/hash pinning for tools and packages: alert or disconnect on definition changes
• Centralized policy at the API/agent gateway: filter the subset of tools returned by tools/list
• Host MCP servers in controlled environments to avoid uncontrolled dynamic changes

🕵️ 9.2 Tool Shadowing

Risk: a malicious tool with a stronger trigger description wraps itself as "whenever the user mentions save/store/remember, use me," overshadowing legitimate tools and exfiltrating sensitive data.

Mitigations:

• Detect and block semantic naming/function collisions (use LLM filtering where needed, not just string matching)
• Use mTLS for high-sensitivity connections, or mutual authentication at the gateway
• Deterministic policy enforcement at key lifecycle points: before discovery, before invocation, before returning results, before outbound requests
• Require Human-in-the-Loop (HIL) confirmation for high-risk operations
• Restrict agents to enterprise-approved MCP servers (local and remote)

🧬 9.3 Malicious Tool Definitions and Contents

Risks:
• Tool descriptions and signature fields can "induce" the planner to misbehave
• Tool-returned external content may carry injected instructions (HTML/Markdown/URLs)
• Returned data may contain sensitive info the model may echo back verbatim

Mitigations:

• Input validation: block path traversal and injection-style parameters (e.g., ../../secrets)
• Output sanitization: filter tokens, PII, URLs, emails, executable content (HTML/Markdown)
• Strictly isolate system instructions from user content; use a "trusted/untrusted dual planner" split when necessary:
• The trusted planner connects only to first-party/authenticated tools
• The untrusted planner connects to third-party tools with restricted communication
• Fetch resources only from allowlisted URLs, with explicit user opt-in/consent
• Sanitize tool descriptions at the gateway before injecting into context

🧷 9.4 Sensitive Information Leaks

Risk: conversation content is often passed to tools as context; tools may gain sensitive info without authorization. Elicitation lets servers request more info via UI—the spec discourages asking for sensitive info, but this isn't enforceable.

Mitigations:

• Use structured tool output, with marking/annotation of sensitive fields
• Adopt "taint tracking": mark tainted sources/sinks
• Default user free text and externally fetched data as tainted
• Treat outbound sending, public writes, and network egress as sensitive sinks requiring extra approval/filtering

🔒 9.5 No Native Scoped Access

Risk: protocol-level authorization is coarse-grained—no per-tool/per-resource authorization or credential-passing mechanism; auditing suffers identity ambiguity about "who actually initiated this."

Mitigations:

• Use audience validation + scoped credentials for tool calls: short expiry, bound to the caller
• Least privilege: read-only wherever possible, not read-write-delete
• Secrets/tokens must never enter model context: keep credentials client-side, send them to servers via an out-of-band secure channel, and prevent them from flowing back into conversations

---

🧩 Chapter 10: A Recommended "Enterprise-Ready" MCP Deployment Pattern

If you're putting MCP into core enterprise systems, assume one rule by default: don't run naked on the pure open-protocol form. A safer engineering shape:

• Host/Agent application: handles orchestration and UX only
• Hardened MCP Client (hardened SDK): tool/server allowlists, schema validation, sensitive-data interception, HIL
• Agent/API Gateway: centralized policy (filtering tools/list, identity verification, mTLS, rate limiting, audit logs)
• Controlled MCP Servers: hosted in managed environments, publishing reviewed tools
• Observability: fold MCP interactions into unified tracing/logging/metrics (the protocol provides no standard; you must add this at the outer layer)

> Tip: Treat MCP as the "USB port," and the gateway as the "enterprise's power-management chip." > USB solves shape uniformity; voltage, current, and overload protection must be guaranteed by higher-level systems.

---

📚 References

1. Model Context Protocol. *What is the Model Context Protocol (MCP)?* https://modelcontextprotocol.io/ 2. Anthropic. *Model Context Protocol Specification (Tools / Schema / Transports / etc.).* https://modelcontextprotocol.io/specification/2025-06-18/ 3. Gan, Tiantian; Sun, Qiyao (2025). *RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation.* https://arxiv.org/abs/2505.03275 4. Hou, Xinyi, et al. (2025). *Model Context Protocol (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