MCP (Model Context Protocol) Explained for Non-AI Engineers

The problem MCP actually solves

Before MCP, connecting an LLM to a third-party service — GitHub, Linear, your internal database — meant writing a bespoke tool integration for that exact model, that exact SDK, that exact prompt format. Every AI product that wanted to talk to ten services wrote roughly the same glue code ten times, and every service that wanted to be usable by AI agents had to publish (or have someone publish) an integration per AI vendor. It's the M×N integration problem software has solved before, in other contexts, with a standard protocol instead of custom adapters.

Model Context Protocol (MCP), originally released by Anthropic and now used across the industry, is that standard. A service exposes an MCP server once; any MCP-compatible AI client — Claude, an agent framework, your own app — can use it without custom integration code.

What MCP actually standardises

An MCP server exposes three kinds of things over a consistent wire protocol:

• Tools — actions the model can invoke (create a Linear ticket, run a GitHub search, query a database), each with a name, description, and a JSON schema for its inputs.
• Resources — data the model can read (a file, a database row, a document) without necessarily calling a tool.
• Prompts — reusable prompt templates the server can offer to the client.

The transport is usually Streamable HTTP. Authentication is layered on top via OAuth — the client (or the platform hosting it) holds a credential scoped to that MCP server's URL, not a bespoke API key format per service.

What it looks like in practice

On Anthropic's own platform, using an MCP server is a declaration, not a custom integration:

{
  "mcp_servers": [
    { "type": "url", "name": "linear", "url": "https://mcp.linear.app/mcp" }
  ],
  "tools": [
    { "type": "mcp_toolset", "mcp_server_name": "linear" }
  ]
}

The model gets access to every tool Linear's MCP server exposes — creating issues, searching, updating status — without your team writing a single Linear-specific function. The same shape works for GitHub, Notion, Slack, or a growing list of vendor-maintained servers, and for a database or internal service you stand up an MCP server for yourself.

Authentication is deliberately separate from the tool declaration. Credentials live in a vault-style credential store keyed to the server's URL — not embedded in a prompt, not hardcoded in the tool config — so the same agent definition can be reused across users or environments with different credentials swapped in underneath it.

What MCP does not give you

It's easy to overestimate scope here, so a few explicit boundaries:

• It's not a replacement for API design. An MCP server is still a server you (or the vendor) build and maintain — you're still deciding what actions to expose and with what guardrails. MCP standardises the wire format and discovery, not your business logic.
• It's not free reliability. A flaky or slow MCP server is exactly as flaky and slow whether the client speaks MCP or a bespoke REST integration. The protocol doesn't fix a bad backend.
• It's not always the right layer. If you're integrating exactly one AI product with exactly one internal service you fully control, a direct function call or tool definition is simpler and has fewer moving parts than standing up a full MCP server. MCP earns its cost when multiple clients, or multiple AI products, need the same integration.

Should you adopt it now?

A few honest, practical guidelines rather than hype:

• Consuming an existing MCP server (GitHub's, Linear's, Notion's) — yes, today. This is the easy, high-value case: point your agent at a vendor's MCP server instead of writing a custom integration. Low cost, immediate leverage.
• Building your own MCP server for internal tools — worth it once more than one AI surface needs the same access. If it's a single chatbot calling a single internal API, skip the ceremony and call the API directly. If you expect multiple agents, multiple teams, or eventually third-party AI clients to need the same access, MCP is the right investment.
• Building an MCP server to sell/expose your product to AI agents generally — increasingly expected. The same way API-first products started publishing OpenAPI specs, AI-relevant products are increasingly expected to publish an MCP server as the standard integration surface.

Where this fits with what we've already covered

If you've read our post on agents vs. copilots vs. chatbots, MCP is specifically the plumbing for the agent case — it's how an agent gets a reliable, authenticated tool surface instead of a pile of one-off API clients. For a chatbot that only reads and answers, you may never need it at all.

Deciding whether MCP fits your stack?

We've built both consumer-side MCP integrations and vendor-side MCP servers. Tell us what you're connecting to what and we'll tell you honestly whether MCP is the right layer or overkill for your case.