Model Context Protocol (MCP)

Every AI app that needs GitHub, Slack, Postgres and your internal billing API used to grow a custom integration per host. Five hosts times twenty systems is a hundred one-off adapters. The Model Context Protocol (MCP) turns that into N + M: you write a server once that exposes tools and data; any compatible host can connect as a client.

Think of it as USB-C for model capabilities. The analogy is imperfect — security and auth still need real design — but the economic point stands. Platform teams want to publish a connector once. Product teams want to stop re-implementing list_issues for every new chat surface.

MCP does not replace tool use. It standardizes how tools, resources and prompts are discovered and invoked. Under the hood the model still sees schemas and emits calls; your process still executes them. If you only have one app and five tools, MCP may be overhead. If you have three hosts and a growing catalog of enterprise systems, it becomes the integration layer.

Concepts in this section

Read them in order. Each one builds on the one before.

Step	Concept	What it answers
1	Hosts, clients and servers	Who owns the app, the connection and the capabilities?
2	Tools, resources and prompts	What can a server expose, and how do you split data from actions?
3	stdio and HTTP transports	Local subprocess, or a shared remote server with OAuth?
4	MCP security	What can a hostile server or a poisoned tool result do?

When plain function calling is simpler

Skip MCP when one app owns the only consumer of the tools, when the tools are bound to that app's session and database transaction, or when you need in-process calls with no subprocess or HTTP hop.

Adopt MCP when several hosts need the same connectors, when non-platform engineers should ship tools without touching every agent codebase, or when you want a package boundary and an audit surface for enterprise data access.

Example

A company built in-process tools for its support bot. Six months later the IDE assistant and an internal ops chat needed the same get_subscription and list_invoices. They extracted an MCP server, pointed all three hosts at it, and deleted two duplicate wrappers. Latency rose by a few tens of milliseconds — acceptable for those tools — and auth bugs were fixed once.

Spec details evolve (transport names, auth profiles, sampling). Build against the current official docs and SDKs. The architecture — host, client, server, and the three primitives — has stayed stable even as transports matured from SSE-centric setups toward streamable HTTP.

Common mistakes

Starting with MCP for a single app. In-process tools are enough until a second host needs the same connector.
A kitchen-sink server. Hosts load every enabled tool into context. Prefer a small, task-level surface.
Trusting server descriptions and tool results. Review, pin and enforce writes in the host.
Exposing a local privileged server over HTTP with no auth. That is a remote shell.

Key takeaways

MCP standardizes connectors so you write a server once for many hosts.
Hosts own policy. Clients connect one-to-one. Servers expose tools, resources and prompts.
Use stdio for local tools. Use streamable HTTP plus OAuth for remote or shared ones.
Design servers like good agent tools: small surface, clear schemas, pagination, least privilege.
Prefer plain function calling for single-app, in-process needs.