Playbook: MCP in Practice — Connect an Agent to an Internal Tool

Before MCP, integrating a tool into an agent was a three-layer problem solved by hand in every project: you needed to (1) serialize the call in the format the model expected, (2) execute the tool logic, and (3) return the result in a format the model could interpret. Each LLM had its own function-calling dialect. Swapping models meant rewriting adapters. Adding a new tool meant touching the agent's code.

MCP inverts the dependency. Instead of the agent knowing how to call each tool, the MCP server announces what it can do — and the agent discovers it at runtime via tools/list. The contract is simple: each tool has a name, a description (free text, read by the model), and an inputSchema (JSON Schema). The agent calls tools/call with the name and arguments; the server executes and returns the result. JSON-RPC 2.0 over stdio or HTTP+SSE.

The analogy I use: think of the MCP server as a microservice with a self-describing contract. The client needs no external documentation — the server itself declares its capabilities. This is what allows a generic agent (Claude, GPT-4, a model on Bedrock) to consume any tool without recompilation. The protocol does the translation work.

One detail that changes everything in practice: the agent chooses which tool to call based on the description, not the name. The model reads the description field as part of the context and decides whether that tool solves what the user asked. This means a bad description — vague, overly technical, lacking examples of when to use it — will cause the agent to ignore the tool or call it at the wrong moment. Treat the description as a fragment of the system prompt, not as a docstring.

When the agent receives the list of available tools via tools/list, the model sees something like this in context:

{
  "name": "search_internal_knowledge_base",
  "description": "Searches documents in the company's internal knowledge base. Use when the user asks about internal policies, HR processes, product technical documentation, or project history. Do NOT use for real-time data questions or information external to the company.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Search text in natural language" },
      "department": { "type": "string", "enum": ["engineering", "hr", "finance", "all"], "default": "all" }
    },
    "required": ["query"]
  }
}

The model reads the description field as an instruction. Three elements make an effective description:

1. When to use (positive): describe the use case in natural language, close to how the user will ask. "Use when the user asks about internal policies" is better than "searches the KB".

2. When NOT to use (negative): this reduces false positives — the agent calling the tool in wrong contexts. Spelling out the negative scope is as important as the positive.

3. Parameter descriptions in inputSchema: each description field inside the schema is also read by the model. "Search text in natural language" instructs the model not to send a technical ID where it should send a phrase.

A common mistake: copying the function name as the description. "description": "search_kb" is useless — the model already has the name. The description needs to add semantic context that the name doesn't carry.

Another mistake: descriptions that are too generic. If you have three search tools and all say "searches for information", the agent will choose randomly or always use the first one. Differentiate with precision.

An MCP tool is not just another API endpoint. It's a capability that a language model can trigger autonomously, based on its interpretation of a natural language instruction. This fundamentally changes the threat model.

In a traditional API, the caller is a deterministic system you control. In an agent with MCP tools, the caller is a model that interprets natural language — and natural language can be manipulated. Prompt injection is the most direct attack: a malicious document in the knowledge base contains instructions for the model to call a tool with specific arguments. If the tool has too much power, the damage is real.

Three principles I apply to any MCP integration before going to production:

1. Least privilege on the server, not the agent. Restricting the agent is pointless if the MCP server has write access to the entire database. The identity running the MCP server should have only the permissions the exposed tools need — and nothing more. On AWS, this means an IAM role with a specific inline policy, not AdministratorAccess.

2. Explicit tool allowlist per agent. An MCP server can expose 20 tools. A specific agent may need 3. Don't expose all of them — configure the client to filter tools/list and present to the model only the tools relevant to the context. This reduces the attack surface and improves the quality of the model's choices.

3. Server-side validation is mandatory — not optional. The JSON Schema in the MCP contract is a description for the model, not a security barrier. The model can generate arguments that pass the schema but are semantically invalid or malicious (path traversal in a file field, SQL injection in a query field). Validate in the handler, before executing any operation with side effects.

Bedrock AgentCore Gateway adds a managed control layer: OAuth 2.1 or IAM authentication, centralized logging, and the ability to revoke access to a specific tool without changing the agent code. For enterprise environments with audit requirements, this layer is worth the additional cost.