What is MCP (Model Context Protocol), and when should you actually build one?

If you've spent any time around AI engineering teams in the last year, you've heard the acronym MCP, usually followed by someone nodding as if they fully understand it. Most of the time they half do. Here's the plain version.

What MCP actually is

Model Context Protocol (MCP) is an open standard for connecting an LLM to external systems: your database, your internal APIs, your file storage, your ticketing system, whatever your business runs on. Before MCP, every team building an AI agent wrote its own custom glue code to give the model access to a specific tool. That code was never reusable outside that one project.

MCP standardizes that connection. A team builds one MCP server for, say, their internal customer database, and any MCP-compatible AI client (Claude, an agent framework, a custom app) can talk to it using the same protocol, without custom integration code on either side.

What an MCP server actually does

An MCP server exposes three kinds of things to a connected AI client:

• Tools: functions the model can call, like search_orders(customer_id) or create_ticket(subject, priority).
• Resources: data the model can read, like a document, a database record, or a config file.
• Prompts: reusable prompt templates the client can surface to the model for common tasks.

The model doesn't get raw access to your systems. It gets access to exactly the tools and resources you define, with whatever permission scoping you build in. That's the part most teams underestimate when they first hear about MCP: the protocol handles the plumbing (and its specification includes an OAuth-based authorization flow for remote servers), but access control, rate limiting, and audit logging are still your responsibility to design well.

When building an MCP server is the right call

We'd recommend it when at least one of these is true:

• You want the same tool access exposed to multiple AI clients (an internal agent, a customer-facing assistant, and a developer's local Claude setup, for example) without maintaining three separate integrations.
• You're building an agent that needs to reason about which tool to use and when, not just execute a fixed sequence of API calls.
• You expect the tool surface to grow. MCP servers are easy to extend with new tools without touching client-side code.
• You want a standard, inspectable interface for what an AI agent can and can't touch in your systems. That matters a lot once security or compliance asks, "what exactly can this agent do?"

When it's overkill

MCP is not the right answer for everything, and we tell clients this directly when it's true:

• If you have one AI feature calling one internal API in one fixed way, a direct function call from your application code is simpler, faster to ship, and has less surface area to secure.
• If you're building a single-purpose chatbot that never needs new tools, the overhead of running and maintaining a standalone MCP server isn't worth it yet.
• If your team doesn't yet have a clear answer to "what should the agent actually be allowed to do?", building the tooling first just moves the problem; it doesn't solve it.

What we've actually built with it

In client engagements, MCP servers have shown up most often in three shapes:

1. Internal knowledge access: an MCP server that lets a support agent query internal documentation, ticket history, and product data, scoped so it can read but never write customer records.
2. Multi-agent tool sharing: several specialized agents (a research agent, a drafting agent, a review agent) sharing one MCP server for company data, so tool definitions and permissions live in exactly one place.
3. Developer tooling: exposing internal systems to engineers' own Claude or agent setups locally, for things like querying staging data or triggering test deployments, without giving every engineer raw database credentials.

The engineering work that actually takes time

Writing the MCP server scaffolding itself is usually the fast part. What takes real engineering time is:

• Deciding the right granularity for tools. Too coarse and the model can't be precise; too fine and it burns context deciding which of twelve nearly-identical tools to call.
• Permission scoping, so the agent's access maps to what a human in that role would actually be allowed to do, not more.
• Testing tool-use reliability. Models sometimes call the right tool with the wrong arguments, or call a tool when they should have asked a clarifying question first. That needs a real evaluation harness, not spot-checking a few conversations.
• Handling failure gracefully: what happens when a tool call fails, times out, or returns something the model doesn't expect. Most of the visible "the AI did something weird" incidents we've debugged for clients trace back to this, not the model itself.

If you're evaluating whether MCP is the right architecture for something you're building, that's exactly the kind of conversation worth having before any code gets written. A short conversation is usually enough to tell whether it's the right tool for your case.