MCP Explained With an Example

#agents #ai #mcp #tutorial

The AI does not know your tools exist. That sentence is the reason MCP exists, and most
explanations skip it.

A language model can only produce text. It cannot read your database, send an email, or
check a calendar. If you want it to do those things, something has to tell it what tools
are available, let it ask for one, run the tool for it, and hand the result back. Before
MCP, every app wrote that plumbing its own way, so a tool built for one assistant did not
work with another.

MCP, the Model Context Protocol, is a shared way of doing that plumbing. Any tool that
speaks MCP works with any assistant that speaks MCP. One plug for every tool.

The three parts

Host: the app the person is using. A chat assistant, a code editor, your own agent.
Client: the small piece inside the host that talks MCP. Usually you never write it.
Server: the thing that owns the tools. A server for your database, a server for GitHub, a server for the file system. Each one publishes a list of what it can do.

The model itself is not any of these. It sits behind the host, sees the list of tools,
and decides which one to ask for.

The handshake, with the real messages

Here is what happens when a host connects to a tiny weather server. The messages are
JSON-RPC, which just means a JSON object with a method name and parameters.

1. Connect and initialize. The client says hello and both sides agree on what they
support.

{"jsonrpc": "2.0", "id": 1, "method": "initialize",
 "params": {"protocolVersion": "2025-06-18",
            "clientInfo": {"name": "my-agent", "version": "1.0"}}}

2. Ask what tools exist. This is the step that matters. The model has no idea what
the server can do until this list comes back.

{"jsonrpc": "2.0", "id": 2, "method": "tools/list"}

The server replies with every tool, its description, and the input it needs:

{"jsonrpc": "2.0", "id": 2, "result": {"tools": [
  {"name": "get_forecast",
   "description": "Get the 3-day weather forecast for a city. Use this when the user asks about upcoming weather, not current conditions.",
   "inputSchema": {"type": "object",
                   "properties": {"city": {"type": "string"}},
                   "required": ["city"]}}
]}}

3. The model chooses. The host puts that list in front of the model along with the
user's question, "Will it rain in Pune this weekend?" The model reads the descriptions
and replies that it wants to call get_forecast with {"city": "Pune"}.

4. Call the tool. The client sends the request. The model does not run anything; the
server does.

{"jsonrpc": "2.0", "id": 3, "method": "tools/call",
 "params": {"name": "get_forecast", "arguments": {"city": "Pune"}}}

5. Get the result back.

{"jsonrpc": "2.0", "id": 3, "result": {"content": [
  {"type": "text", "text": "Sat: rain, 24C. Sun: cloudy, 26C. Mon: clear, 28C."}
]}}

6. The model answers the person. The host feeds the result back to the model, and
the model turns it into a sentence: "Yes, Saturday looks wet. Sunday should be dry."

Ask, choose, run, reply. That is the entire protocol in practice.

The mistake that breaks most MCP setups

Look at step 2 again. The description field is the only thing the model has when it
decides which tool to call. It is not documentation for humans. It is the interface.

A server with two tools described as "Get weather" and "Get weather data" will make the
model guess, and it will guess wrong about half the time. Then you spend an afternoon
blaming the model when the real problem was one vague sentence.

Write descriptions the way you would brief a new colleague: what the tool does, when to
use it, and when not to. The forecast tool above says "upcoming weather, not current
conditions" for exactly that reason. If you also have a get_current_weather tool, that
one line is what stops the model from mixing them up.

When you do not need MCP

If your agent has three tools and you wrote all three yourself, plain function calling is
simpler. MCP earns its place when tools and assistants are built by different people:
you want to plug a database server someone else wrote into an assistant you did not
build. That is the N by M problem, N assistants times M tools, and MCP turns it into
N plus M.

Where to go from here

The LogicWiz GenAI course animates this handshake so you can watch each message go across:
Enter MCP, one plug for every tool,
the MCP handshake, and
when, and when not, to use MCP. There is also a chapter on
A2A, the protocol for agents talking to other agents. The whole course is completely free, with no card. Chapters one to three open without an account, and from chapter four a free account keeps you going.

Originally published on LogicWiz.

DEV Community