Skip to content
FLAVIO COPES
flaviocopes.com

What is MCP, the Model Context Protocol

By

Learn what MCP is, how clients and servers work, what tools, resources, and prompts do, and how an AI agent makes a tool call.

~~~

MCP is a standard way for AI applications to connect to external tools and data.

The full name is Model Context Protocol.

It lets an application such as Claude, Cursor, or another coding agent discover what a service can do, call its tools, and read the results using one shared protocol.

MCP does not make the model smarter. It gives the application around the model a standard way to reach other systems.

The problem MCP solves

Suppose you want an AI agent to:

The model cannot do those things by itself. It needs code that connects to each service.

Before MCP, every AI application needed a custom integration for every service. A GitHub integration written for one client could not automatically work in another.

MCP gives both sides a shared contract.

A service describes its tools in a standard format. Any compatible client can discover and call them.

The three parts of MCP

An MCP setup has three main parts: a host, a client, and a server.

The host

The host is the AI application you use.

Claude Desktop, an IDE, or a coding agent can act as an MCP host. It manages the conversation, sends information to the model, asks for permission, and displays results.

The client

The host contains an MCP client that speaks the protocol.

The client connects to a server, discovers its capabilities, sends requests, and receives results. A host can connect to several MCP servers at the same time.

You usually do not interact with this layer directly. The host manages it for you.

The server

The MCP server provides access to a system.

It can be a local program running on your computer or a remote service running over HTTP. The server translates MCP requests into real operations against files, APIs, databases, or other services.

For example, a GitHub MCP server receives an MCP tool call, calls the GitHub API, then returns the result in the MCP format.

What an MCP server can expose

An MCP server can provide tools, resources, and prompts.

Tools

A tool performs an action or calculation.

Examples:

Each tool has a name, description, and input schema. The schema tells the model which arguments the tool accepts.

A tool description might look like this:

{
  "name": "get_deployment_logs",
  "description": "Return recent logs for a deployment",
  "inputSchema": {
    "type": "object",
    "properties": {
      "deploymentId": {
        "type": "string"
      }
    },
    "required": ["deploymentId"]
  }
}

The model sees this description and can decide when the tool is useful.

Resources

A resource is data the client can read.

A server might expose a file, configuration document, database schema, or API response as a resource. Resources have addresses, similar to URLs, that identify what the client should fetch.

Tools perform work. Resources provide context.

Prompts

A prompt is a reusable message template.

For example, a server could provide a prompt for reviewing an incident or preparing a deployment. The host can present that prompt to the user and fill in its arguments.

Prompts are useful for packaging a known workflow alongside the tools and data it needs.

How an MCP tool call works

Suppose you ask your coding agent:

Show me the errors from deployment deploy_82f1.

Here is what happens:

  1. The host sends the conversation and available tool descriptions to the model.
  2. The model decides to use get_deployment_logs.
  3. The model returns the tool name and deploymentId argument.
  4. The host checks permissions and asks for approval when needed.
  5. The MCP client sends the tool call to the server.
  6. The server fetches the logs from the deployment platform.
  7. The server returns the result to the client.
  8. The host gives the result to the model.
  9. The model explains the errors to you.

The model does not call the deployment API directly. The MCP server does the real work.

The host stays in the middle. It controls connections, permissions, and what information enters the conversation.

Local and remote MCP servers

MCP servers usually connect in one of two ways.

Local servers with stdio

A local client can start an MCP server as a child process. They communicate through standard input and output, usually called stdio.

This works well for filesystem tools, local databases, and development utilities. You do not need to open a network port or deploy anything.

A client configuration might look like this:

{
  "mcpServers": {
    "project-tools": {
      "command": "node",
      "args": ["/Users/flavio/mcp/project-tools.js"]
    }
  }
}

The exact configuration format depends on the client.

Remote servers with HTTP

A remote MCP server runs on another machine and receives requests over HTTP.

This is useful when a team shares the same server or when the tools connect to a cloud service. Remote servers also need authentication because they are reachable over a network.

The current MCP specification uses self-contained HTTP requests. This makes remote servers easier to deploy behind load balancers and on serverless platforms.

LLM function calling lets a model return a structured request for a function.

MCP builds a wider protocol around that idea. It standardizes how applications discover tools, call them, read resources, use prompts, handle authorization, and communicate with servers.

Function calling is the model saying:

Call this function with these arguments.

MCP defines how the surrounding application finds that function and carries the request to the server that implements it.

MCP does not replace APIs

An MCP server usually sits in front of an existing API, database, or local program.

It does not replace the GitHub API. It gives AI clients a standard way to use a carefully selected part of that API.

MCP is also not an agent. The model and host decide what to do. The server exposes capabilities and executes requests.

You still need to design good tools, validate their inputs, handle errors, and protect credentials.

Be careful with MCP servers

MCP tools can read private data and perform real actions.

Treat an MCP server like any other program with access to your computer or cloud account.

My advice is:

A standard protocol does not make an unsafe integration safe. It makes integrations compatible.

When MCP is useful

MCP is useful when you want the same integration to work across several AI applications.

It also helps when a tool provider wants to publish one server instead of maintaining separate connectors for every client.

You may not need MCP for a small application with one model and two internal functions. Calling those functions directly can be simpler.

Use MCP when interoperability matters: one standard connection between many AI clients and many external systems.

The official MCP documentation is the best place to explore clients, servers, SDKs, and the current specification.

Tagged: AI ยท All topics
~~~

Related posts about ai: