What Is the Model Context Protocol (MCP) and Why Use It?

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools, data and prompts through one common interface. Instead of writing a custom integration for every pairing of AI app and service, you write an MCP server once and any MCP-aware application can use it.

The problem MCP solves

A language model on its own only knows what was in its training data and what you put in the prompt. To be useful in real work it needs to read your files, query your database, create tickets and call your internal APIs. Before MCP, every AI application solved this in its own way. A code editor had its own plugin format. A chat app had another. An agent framework had a third.

If you have M AI applications and N services, you end up with up to M x N custom integrations. Each one needs its own authentication code, its own schema format and its own maintenance. MCP turns that into M + N: each application implements the client side once, each service implements the server side once, and they all speak the same protocol.

A common comparison is USB-C. You do not need a different cable for each device and each computer. You need a shared connector and a shared set of rules.

What MCP actually defines

MCP is a protocol, not a library or a product. It defines:

• Message format. Messages are JSON-RPC 2.0 requests, responses and notifications.
• Lifecycle. How a client and server connect, agree on capabilities and shut down.
• Primitives. The things a server can offer: tools, resources and prompts. Clients can also offer features to servers, such as sampling and roots.
• Transports. How messages travel: standard input and output for local processes, and Streamable HTTP for remote servers.
• Authorization. An OAuth-based approach for protecting remote servers.

Official SDKs exist for several languages, including TypeScript and Python, so you rarely handle the raw JSON yourself. You will use both of those SDKs throughout this course.

A concrete example

Imagine you want an AI assistant to answer questions about a company's sales database. Without MCP you would write glue code inside that one assistant: a function to run SQL, a schema description for the model, and code to feed results back. If you later want the same ability in a different assistant, you write it again.

With MCP you write a small server that exposes a run_query tool and a resource describing the schema. Then you point any MCP-capable application at it. The tool definition, including its name, description and input schema, is sent to the client automatically, so the model knows how to call it.

Here is what a minimal server looks like with the TypeScript SDK. You will build this properly in a later post. For now, notice how little code the integration needs.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "hello", version: "1.0.0" });

server.registerTool(
  "greet",
  {
    description: "Return a greeting for a person",
    inputSchema: { name: z.string().describe("Name of the person") },
  },
  async ({ name }) => ({
    content: [{ type: "text", text: "Hello, " + name + "!" }],
  })
);

await server.connect(new StdioServerTransport());

Why teams adopt MCP

• Reuse. One server works in several clients, so the effort is not wasted when you change tools.
• Separation of concerns. The people who own a service can ship its MCP server. The people who build the AI application just connect to it.
• Discovery. Clients ask the server what it offers at runtime, so adding a tool does not require changing the client.
• A growing ecosystem. Many existing servers cover common systems, so you can often start by configuring instead of coding.

When MCP is not the right choice

MCP adds a moving part. If you have a single application with two or three tools that only it will ever use, plain function calling with your model provider's API is simpler. MCP pays off when you want reuse across applications, when tools are owned by a different team, or when users should be able to plug in their own servers. A later post compares MCP with function calling and REST in detail.

Also remember that MCP standardizes the connection, not the safety. A server that can delete files or send emails is just as dangerous through MCP as through any other path. Later parts of this course cover authorization and security in depth.

What to do next

1. Read the next post on hosts, clients and servers to learn the vocabulary.
2. Build a first server in TypeScript or Python.
3. Connect it to a client and watch the model call your tool.

By the end of this course you will be able to design, secure, test and deploy MCP servers for real systems.