What is the Model Context Protocol, and what problem does it solve?

4 minbeginnermcpfundamentalsarchitecture

Quick Answer

MCP is an open protocol (originally released by Anthropic in November 2024) that standardizes how applications feed context, tools, and data to LLMs. Before MCP, every app that wanted an LLM to read a file, query a database, or call an API wrote a custom, one-off integration. MCP replaces those M×N custom integrations with a single, shared protocol: any MCP client (Claude Desktop, an IDE, a custom agent) can talk to any MCP server (a Slack connector, a Postgres server, a filesystem server) without either side knowing about the other in advance. It's often compared to a USB-C port for AI applications: one standard connector instead of a different cable for every device.

Detailed Answer

Think about LLM integrations before MCP existed. Say you built a chat app. You wanted it to read GitHub issues, query a database, and search internal docs. You had to write three separate, custom integrations. Each had its own auth. Each had its own way of describing what it does. Now say another team built a different chat app. They wrote the same three integrations again, from scratch. This is the M×N problem: M applications, each writing custom code for N data sources.

The core idea

MCP turns that into an M+N problem. Anyone can write one MCP server for a data source (say, Postgres) once, following the spec. Anyone can write one MCP client for their app once. Any client can then talk to any server, because both sides speak the same protocol.

Without MCP:                     With MCP:

App A ---- GitHub integration    App A --\
App A ---- Postgres integration          MCP protocol --- GitHub server
App B ---- GitHub integration    App B --/              --- Postgres server
App B ---- Postgres integration

What MCP actually standardizes

MCP defines:

  • A base message protocol (JSON-RPC 2.0) for requests, responses, and notifications.
  • A lifecycle: how a client and server discover each other's capabilities and agree on a protocol version.
  • A small set of primitives — tools, resources, and prompts on the server side; sampling, roots, and elicitation on the client side. Together they cover most of what an LLM integration needs.
  • Transports (stdio for local processes, Streamable HTTP for remote services). The same protocol works whether the server is a subprocess on your laptop or a hosted web service.

Why this matters in practice

A tool vendor (say, a project-management SaaS) can ship one official MCP server covering this list, once. Every AI app that supports MCP — Claude Desktop, Claude Code, various IDEs and agent frameworks — connects to it right away:

  • No vendor-specific glue code on either side.
  • No re-implementing the same integration for every new host application.
  • No coordination needed between the server author and any particular client author.

Related Resources