Skip to main content

Intro to the Model Context Protocol (MCP)

If your agent has ever needed to read your CRM, query a database, search a knowledge base, or post to Slack, you have already faced the problem MCP solves. MCP is a standard way to plug tools and data sources into AI agents, so you stop wiring every model to every system one bespoke integration at a time.

Think of it as USB-C for AI. Before USB-C, every device had its own connector. After USB-C, one cable, many devices. MCP is the same idea applied to "things an agent can read or call."

The problem MCP solves​

Without a standard, every agent integration looks like this:

Three agents × three systems × custom auth, schemas, and error handling = nine fragile integrations. Add a fourth system and you have twelve.

With MCP:

Three agents × one MCP layer + three MCP servers (one per system) = three integrations, reused everywhere.

What MCP actually is​

A protocol with three building blocks:

ConceptWhat it isReal-world analog
HostThe application the user interacts with — Claude Desktop, Cursor, your own product.The phone that the USB cable plugs into.
ClientThe piece inside the host that speaks MCP.The USB controller.
ServerA small program that exposes tools, resources, and prompts for one system (a CRM, a database, a Git repo).The peripheral on the other end of the cable.

A server can offer:

  • Tools — functions the agent can call (e.g. searchCustomers, createTicket).
  • Resources — read-only data the agent can pull in (e.g. files, query results).
  • Prompts — pre-written templates the host can offer the user.

The host discovers what each server provides, presents it to the model, and brokers the calls.

How it differs from "just calling an API"​

MCP is not a replacement for REST APIs. It is a layer on top.

Plain API callMCP server
Custom code per agent.Written once, reused by any MCP-aware host.
Schemas live in your prompt.Schemas are advertised by the server; the host wires them into the model's tool list.
Auth handled per integration.Auth handled at the server boundary, away from the model.
Discovery is a doc page.Discovery is programmatic — hosts can list available tools at runtime.

For a one-off internal script, a direct API call is fine. For an organization that will run many agents against many systems, MCP eliminates the N×M integration problem.

Why this matters for agents​

Recall the agent architecture standards: separate agent logic from tool integration. MCP is the cleanest way to enforce that separation. The agent's prompt names the tool; the MCP server is the tool's implementation; the host is the boundary between them.

This also slots cleanly into governance:

  • The "approved tool list" in your Role/Goal/Backstory Operating Rules becomes "the MCP servers this agent's host has loaded."
  • HITL approvals (see Governance & HITL) can intercept any MCP tools/call before it executes.
  • Agent Security controls — least privilege, credential isolation, output filtering — apply at the server boundary, where they belong.

When to adopt MCP​

  • You probably should if you are building more than one agent, or one agent against more than two systems, or shipping integrations into a host like Claude Desktop or Cursor.
  • You can wait if you have a single workflow against a single API and you do not expect to grow beyond it.

Common gotchas​

  • Tools are not free. Every MCP server you load adds tokens to the model's context. Curate the toolset per agent.
  • Schemas matter. A vague tool description leads the model to guess. Treat the tool's description like a mini system prompt.
  • Trust boundary. An MCP server is code running with whatever credentials it holds. Vet third-party servers like you would any other dependency.
  • Latency stacks. Host → server → backing system → back. Profile and cache where it makes sense.

Where to go from here​

Need help implementing or feeling stuck? Contact us today to establish a consulting relationship.