MCP Explained With an Example

The Model Context Protocol in plain English, with the actual messages that go back and forth when an AI connects to a tool. Why it exists, what the handshake looks like, and the one mistake that breaks most MCP setups.

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.