Model Context Protocol (MCP): How Claude Connects to Your Tools

By Carlos Montiel | Enterprise AI Specialist
Leer en español →
Published: 2026-07-28 | By: Carlos Montiel | Reading time: ~6 minutes

MCP solves a very concrete problem: without a standard, every integration of an LLM with an external tool is a custom connector you have to rewrite for every model and every client.

The problem MCP solves

Before MCP, connecting a language model to a database, a ticketing system, or a file repository meant writing a proprietary adapter for every model-and-tool combination. Model Context Protocol, published by Anthropic as an open standard, defines a common protocol based on JSON-RPC 2.0 so that any MCP-compatible client (Claude Desktop, Claude Code, or your own application with the Claude Agent SDK) can talk to any MCP server with no tool-specific integration code.

The right analogy is USB-C for AI agents: a standard port where the model side doesn't need to know the tool side's implementation details, and vice versa.

Architecture: hosts, clients, and servers

MCP defines three roles. The **host** is the application the end user uses (Claude Desktop, an IDE, your product). The **MCP client** lives inside the host and maintains a 1:1 connection with each **MCP server**. The server exposes three types of primitives:

- **Tools**: functions the model can invoke with structured arguments (equivalent to `tool_use` in Claude's Messages API), for example `create_issue(title, description, project)`. - **Resources**: read-only data the host can expose to the model as context — a file, a database row, the result of a query. - **Prompts**: reusable prompt templates the server exposes for common workflows.

The transport can be stdio (the server runs as a local subprocess, ideal for development tools) or HTTP with Server-Sent Events / Streamable HTTP (for remote servers, like the ones used by hosted GitHub, Slack, or Linear integrations).

How this interacts with the Claude API

In the Claude API, the `mcp_servers` parameter lets Claude connect directly to a remote MCP server without your code mediating every call — Anthropic manages the server-side connection. You declare the server and an `mcp_toolset`-type tool that references that server by name:

response = client.beta.messages.create( model="claude-opus-4-8", max_tokens=1024, betas=["mcp-client-2025-11-20"], mcp_servers=[ {"type": "url", "url": "https://mcp.example.com/sse", "name": "internal-erp"} ], tools=[{"type": "mcp_toolset", "mcp_server_name": "internal-erp"}], messages=[{"role": "user", "content": "Check inventory for SKU 4821"}], )

Alternatively, if you need to run the MCP server locally (for example, a stdio server wrapping your internal database), the Python and TypeScript SDKs offer helpers to convert MCP tools, prompts, and resources into the API's native types and use them with the tool runner.

Authentication and security in production

An MCP server that exposes actions with side effects (creating tickets, sending emails, modifying records) needs the same security guarantees as any internal API: OAuth or token authentication, role-based access control, and auditing of every invocation. In the context of Anthropic's Managed Agents, MCP server credentials are managed through "vaults" — the model never sees the secret, which gets injected into the outgoing request after it leaves the execution sandbox.

For simpler integrations, in Claude Code or Claude Desktop, configuration lives in a JSON file declaring which servers are enabled and their environment variables or tokens, deserving the same care you'd give any configuration file containing secrets.

Available MCP servers and when to build your own

There's a growing ecosystem of MCP servers maintained by third parties and by Anthropic: GitHub, Google Drive, Slack, Postgres, Puppeteer for browser automation, and dozens more listed in the public reference repository. Before building your own server, it's worth checking whether one already exists for the system you need to connect.

Building your own MCP server makes sense when you need to expose internal business logic — for example, a server that wraps your ERP or billing system with your company's specific validations. The official MCP SDK (available in Python, TypeScript, Java, Kotlin, and C#) reduces this to defining decorated functions with their input schema; the protocol handles the rest.

MCP vs. native tool use: when to use each

If your agent only needs a handful of tools specific to your application, defining tools directly in the Messages API (the standard `tools` parameter) is simpler and doesn't require maintaining a separate server. MCP is justified when: (1) the same tool needs to be consumed by multiple different clients or models, (2) the tool's provider already publishes a maintained MCP server, or (3) you want to decouple the integration's lifecycle from your agent application's lifecycle. At Guatemalia, for example, an MCP server for the internal document management system lets both Claude Code and a future customer-service integration reuse exactly the same access layer, without duplicating logic.

Carlos Montiel
Enterprise AI Solutions Architect
Specialist in LLMs, Agents, and Orchestration
guatemalia.com/en/#contact · info@guatemalia.com

Need to implement AI at your company?

Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.

Contact Carlos Montiel

info@guatemalia.com