By Vamsi Krishna
Engineering · · Discuss
Series5 Days of MCP for Production AI Part 1 of 5
  1. Part 1: What the MCP protocol actually standardises
  2. Part 2: Where your MCP server runs is a production decision
  3. Part 3: Tools, resources and prompts are not interchangeable
  4. Part 4: A clean connector does not make a reliable agent
  5. Part 5: When MCP earns its overhead, and when a direct API is better

Most teams meet MCP as a config block they paste into an app. It works immediately, and that tends to be the end of the thinking.

Then someone asks who owns the connector, and the room goes quiet.

MCP standardises one narrow thing: how an application discovers and calls capabilities that live outside it. That is genuinely useful. It is also much smaller than the word "protocol" makes it sound.

Four boxes, and the blur is always in the same place

The host is the application the user actually trusts. Claude Desktop, an IDE, your internal chat product. It owns the conversation and the decisions.

The client lives inside the host, one per connected server, and manages that session.

The server exposes capabilities. It might be a twenty-line local script or a service your platform team operates.

The external system is what the server is really talking to: Postgres, Jira, a filesystem, an internal API.

Trouble almost always starts between host and server. Teams put judgment in the server ("only return rows this user should see") when judgment belongs to the host, or they bury connection and retry logic in the host when it belongs to the server.

Three primitives, and they are not interchangeable

Capabilities come in three shapes, and the distinction is not cosmetic:

  • Tools are model-invoked. The model decides to call them. Side effects live here.
  • Resources are application-controlled context. The host decides what to include. Read-only.
  • Prompts are user-invoked templates. A person picks them deliberately.

Collapse all three into "tools" and you have handed the model authority to trigger anything, including things a human was supposed to choose.

Before you write any server code

Draw the four boxes. Then, for every capability you intend to expose, answer three questions: which primitive is it, who owns it when it breaks, and what gets logged when it runs.

If a capability has no owner, it is not ready to be exposed. A connector nobody maintains is a liability that happens to work today.

The protocol will not make any of these decisions for you. It only makes them expressible.

Part 1 of 5 Days of MCP for Production AI.