What are the key components involved in MCP interactions?

What you need to know

1. Discover — learn protocol versions and capabilities (server/discover, or initialize on older servers).
2. List — tools/list returns each tool's name, description, inputSchema and optional outputSchema and annotations.
3. Assemble — convert MCP tools into the model API's tool format and add them to the request.
4. Invoke — map the model's tool call to tools/call; map the result back to a tool result.
5. Update — re-list when the server says its list changed.

Bridging MCP to a model API

The host's job is translation. With the Anthropic API:

1# Python MCP SDK v2 field names; v1 uses inputSchema and isError2async def mcp_tools_for_model(session, prefix):3    listed = await session.list_tools()4    return [{"name": f"{prefix}__{t.name}",5             "description": t.description,6             "input_schema": t.input_schema} for t in listed.tools]78async def run_mcp_call(session, block, prefix):9    result = await session.call_tool(block.name.removeprefix(f"{prefix}__"), block.input)10    text = "\n".join(c.text for c in result.content if c.type == "text")11    return {"type": "tool_result", "tool_use_id": block.id,12            "content": text, "is_error": bool(result.is_error)}

The prefix avoids name clashes when two servers both expose search. Note how the MCP result's error flag (isError on the wire) becomes the API's is_error: the model sees the failure and can recover.

Tool results

A tools/call result can hold:

• content — a list of text, image, audio, resource links or embedded resources.
• structuredContent — a JSON value matching the tool's outputSchema, for programs to use.
• isError: true — a tool execution error (bad input, API failure) the model should see and fix. This is different from a JSON-RPC protocol error (unknown tool, malformed request).

Server asking for input

Sometimes a server needs something mid-call — for example the user's confirmation or a missing value. In the current spec, the server replies with an "input required" result listing what it needs (for example an elicitation form); the host asks the user and retries the original request with the answers. The older sampling (server asks the host's model for a completion) and roots (host tells the server which folders it may use) features still work but are deprecated as of 2026-07-28.

Change notifications

A server that declares listChanged can tell subscribed clients notifications/tools/list_changed; the client then calls tools/list again. tools/list results also carry a ttlMs freshness hint so clients can cache the list.

A real-life example

A SQL analytics agent connects to a Postgres MCP server with read-only credentials.

1. Discover and list: the server offers list_tables, describe_table and run_readonly_query, each with an input schema; the query tool also has an outputSchema for {columns, rows, truncated}.
2. Assemble: the host adds them to the Claude request as pg__list_tables, pg__describe_table and pg__run_readonly_query.
3. Invoke: the model calls pg__run_readonly_query with a query that references a column that does not exist. The server returns isError: true with "column order_ts does not exist; did you mean ordered_at?". The host passes it back as is_error, and the model fixes the query on the next turn.
4. Update: the data team adds a sample_rows tool; the server sends list_changed, the host re-lists, and the new tool is available on the next conversation.

Follow-up questions to expect

• "What is the difference between content and structuredContent?" — content is for the model and humans to read; structuredContent is typed JSON for programs, validated against outputSchema. Servers usually send both.
• "How should the host treat protocol errors?" — Log them and fix the integration; they rarely help the model. Tool execution errors should go to the model.
• "Why prefix tool names?" — Tool names are only unique within one server; aggregating several servers can create clashes.