Lesson 4: Follow One Request From Prompt to Result

In this lesson you will:

• Follow one question through discovery, tool listing, approval and a tool call.
• Read the actual JSON messages an MCP client and server exchange.
• See what happens when a server needs more input or a tool fails.

You now know the roles from Lesson 2 and the building blocks from Lesson 3. This lesson puts them in motion. You do not need to write code, but you will read a few short JSON snippets. JSON is just labeled text in curly braces.

1. The scenario

You have a weather server connected to your AI app. You type: "What's the weather in San Francisco?"

The MCP architecture overview uses this same example. All JSON below is copied or trimmed from that page. It reflects the 2026-07-28 specification, the latest as of October 2026.

2. Step one: discovery (optional)

The client may first ask the server what it supports. It sends a server/discover request. The docs say every server must implement it, and calling it is optional.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

Read it line by line. method is the question being asked. id links this request to its answer. The _meta block says which protocol version the client speaks, who the client is, and what it can do. Here it can handle elicitation.

The server replies with its supported versions and capabilities, such as "tools": { "listChanged": true }. The reply also carries ttlMs, a hint for how long the answer can be cached. Our server discovery reference covers this in depth.

3. Step two: list the tools

Next the client sends tools/list. The server answers with each tool's name, description and input schema. Trimmed to one tool:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": { "type": "string", "description": "City name, address, or coordinates (latitude,longitude)" },
            "units": { "type": "string", "enum": ["metric", "imperial", "kelvin"], "default": "metric" }
          },
          "required": ["location"]
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

required says location must be supplied. units is optional and defaults to metric. A ttlMs of 300000 milliseconds means this list can be cached for five minutes.

4. Step three: the host combines tools and the model picks one

The host collects tools from every connected server into one list. The docs describe it as "a unified tool registry that the language model can access."

The AI model reads your question and the tool descriptions. It decides weather_current fits, with location set to "San Francisco." This is why clear tool descriptions matter so much.

5. Step four: approval

Before the call goes out, the host can show you what is about to happen. The tools page of the spec says there "SHOULD always be a human in the loop with the ability to deny tool invocations."

The same page says clients should "show tool inputs to the user before calling the server." That helps you catch an accidental or malicious leak of data. The spec's security principles go further: hosts "must obtain explicit user consent before invoking any tool."

How this looks depends on your app. You will configure it in Lesson 10.

6. Step five: call the tool

Once approved, the client sends tools/call with the tool name and arguments:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

Notice the _meta block again. Every request repeats it. The architecture overview calls MCP "a stateless protocol": "every request contains all the information needed to process it." See why MCP became stateless.

7. Step six: the result comes back

The server runs the tool and replies:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"
      }
    ]
  }
}

The id of 3 matches the request. The content array can hold text, images or other types. The host hands this to the model, which writes your answer in plain language.

8. When the server needs more from you

Sometimes a server cannot finish without asking you something. In the 2026-07-28 spec, it does not send its own request. It returns a result with "resultType": "input_required" listing what it needs.

The tools page shows a server asking for a GitHub username through an elicitation/create form. Your app shows the question. The client then retries the original tools/call with your answer in inputResponses, using a new request ID.

This pattern is called multi round-trip requests. Our multi round-trip reference walks through it.

9. When a tool fails

The spec separates two kinds of errors:

• Protocol errors, such as an unknown tool name, come back as standard JSON-RPC errors.
• Tool execution errors, such as a date in the wrong format, come back as a normal result with "isError": true and a message.

The second kind is meant for the model. The spec says clients "SHOULD provide tool execution errors to language models to enable self-correction." So the AI can read "date must be in the future," fix its input and try again.

Try it

Look back at the JSON in steps 3, 6 and 7. Answer these without scrolling ahead:

1. Which field links a response to its request?
2. What happens if the model calls weather_current without units?
3. Which field makes this request "stateless"?
4. In the result, what type of content came back?
5. If the location were misspelled and the server said so, would you expect a JSON-RPC error or isError: true?

Answers: 1) id. 2) It uses the default, metric. 3) The _meta block with protocol version and client capabilities, sent on every request. 4) text. 5) Most likely isError: true, because it is an input problem the model can fix.

Recap

One MCP request follows a clear path: optional discovery, tools/list, the model's choice, your approval, tools/call, and a result. Each message is JSON-RPC with an id, and each request carries _meta so the server stays stateless. Servers that need more input reply "input required," and fixable tool errors come back with isError: true. Next, Lesson 5 covers how these messages travel to local and remote servers.

Course navigation

Previous lesson: Lesson 3: Tools, Resources and Prompts.

Next lesson: Lesson 5: Local and Remote Servers (Transports).

Back to the Learn MCP course outline.

Frequently asked questions