# Two Protocols, Three Translations: How a Host Bridges MCP and an LLM Provider API > Source: > Published: 2026-10-05 17:43:25+00:00 **Following one question through the MCP stack — from the user's prompt to the final answer** Modern AI applications increasingly sit between two different worlds: **MCP (Model Context Protocol)** and an **LLM provider API**. MCP provides a standardized way for an AI application to discover and invoke external tools. The LLM provider API provides the interface through which the application sends prompts, tool definitions, and tool results to the model. The important part is that these two systems do not necessarily speak the same format. The **Host** sits between them. The Host discovers tools from an MCP Server, translates those tools into the format expected by the LLM provider, receives the LLM's tool decision, translates that decision back into an MCP request, executes the tool, and finally translates the result back into the provider's format so the LLM can produce a natural-language response. This creates a useful mental model: **Two protocols. Three translations. One complete tool-call lifecycle.** In this article, we will follow one simple question through the entire process: **"What is 5 plus 7?"** Our MCP Server exposes one tool: ``` php add_numbers(a: number, b: number) -> number ``` We will follow the request through **20 steps**, divided into four phases: Before looking at the 20 steps, we need to understand the components involved. The architecture looks approximately like this: ``` ┌──────────────────┐ │ USER │ │ "What is 5 + 7?" │ └────────┬─────────┘ │ ▼ ┌──────────────────┐ │ HOST │ │ │ │ Agent / │ │ Orchestrator │ └────────┬─────────┘ │ MCP / JSON-RPC │ ▼ ┌──────────────────┐ │ CLIENT │ └────────┬─────────┘ │ ▼ ┌──────────────────┐ │ SERVER │ │ │ │ Tool Registry │ │ │ │ add_numbers │ └──────────────────┘ ┌──────────────────┐ │ HOST │ └────────┬─────────┘ │ Provider API │ ▼ ┌──────────────────┐ │ LLM │ │ │ │ Tool selection │ │ Argument creation│ └──────────────────┘ ``` The most important thing to understand is that there are two protocol boundaries. The first is the **MCP side**. The MCP Client and MCP Server communicate using MCP messages based on JSON-RPC. For example: ``` { "method": "tools/list", "id": 1 } ``` Or: ``` { "method": "tools/call", "params": { "name": "add_numbers", "arguments": { "a": 5, "b": 7 } }, "id": 2 } ``` The second side is the **LLM provider API**. The Host does not simply send those MCP JSON-RPC messages directly to the LLM. Instead, the Host translates the MCP tool definition into the format expected by the provider. For example, conceptually: ``` { "name": "add_numbers", "description": "Adds two numbers", "parameters": { "type": "object", "properties": { "a": { "type": "number" }, "b": { "type": "number" } }, "required": [ "a", "b" ] } } ``` The LLM can then respond with a provider-specific tool or function call such as: ``` { "function_call": { "name": "add_numbers", "arguments": "{\"a\":5,\"b\":7}" } } ``` The Host then translates this back into an MCP `tools/call` request. That is the bridge. The first phase answers one fundamental question: **What tools are available?** At this point, the LLM has not yet been asked to solve the user's question. The Host first needs to discover what tools are available from the MCP Server. The user enters: ``` What is 5 plus 7? ``` The Host receives this prompt. At this moment, the Host knows what the user wants, but it may not yet know what tools are available on the connected MCP Server. The Host's orchestration layer starts the agent process. Conceptually, we could imagine something like: ``` await agent.run("What is 5 plus 7?"); ``` The Host now needs to discover the tools that are available. It asks the MCP Client to perform tool discovery. The MCP Client sends an MCP request to the Server. Conceptually: ``` { "method": "tools/list", "id": 1 } ``` This is an MCP request using JSON-RPC. The important point is that this message is part of the MCP communication between the Client and Server. The LLM is not involved yet. The MCP Server receives the `tools/list` request. The server maintains a tool registry. Conceptually, the registry might contain: ``` { name: "add_numbers", description: "Adds two numbers", inputSchema: { ... }, handler: ... } ``` The registry contains both the public definition of the tool and the executable handler. However, the Server does not send the implementation of the handler to the Client. Instead, it exposes the public contract: ``` name description input schema { "name": "add_numbers", "description": "Adds two numbers", "inputSchema": { "type": "object", "properties": { "a": { "type": "number" }, "b": { "type": "number" } }, "required": [ "a", "b" ] } } ``` The Server is effectively saying: "I have a tool called `add_numbers`. It accepts two numbers: `a` and `b`." The Server responds to the Client. ``` { "id": 1, "result": { "tools": [ { "name": "add_numbers", "description": "Adds two numbers", "inputSchema": { "type": "object", "properties": { "a": { "type": "number" }, "b": { "type": "number" } }, "required": [ "a", "b" ] } } ] } } ``` Notice what was returned. The Server returned: ``` name description schema ``` It did not return: ``` the implementation of the function ``` The handler remains on the Server. The MCP Client receives the response. It passes the discovered tools back to the Host. The Host now knows: ``` Tool: add_numbers Arguments: a: number b: number ``` The discovery phase is complete. The Host can now tell the LLM what tools are available. This is where one of the most important architectural concepts appears. The Host has an MCP tool definition. But the LLM provider does not necessarily understand MCP's tool representation. Therefore, the Host must perform a translation. The Host converts the MCP tool schema into the tool/function schema expected by the LLM provider. ``` MCP Tool Schema | | Translation #1 v LLM Provider Tool Schema ``` The MCP tool might look conceptually like: ``` { "name": "add_numbers", "description": "Adds two numbers", "inputSchema": { "type": "object", "properties": { "a": { "type": "number" }, "b": { "type": "number" } }, "required": [ "a", "b" ] } } ``` The Host transforms it into something the provider understands: ``` { "name": "add_numbers", "description": "Adds two numbers", "parameters": { "type": "object", "properties": { "a": { "type": "number" }, "b": { "type": "number" } }, "required": [ "a", "b" ] } } ``` The exact field names depend on the provider. The important concept is the translation. The Host is acting as an adapter between MCP and the provider API. The Host now has two pieces of information: ``` User prompt: "What is 5 plus 7?" Available tool: add_numbers ``` The Host sends both to the LLM provider. ``` { "messages": [ { "role": "user", "content": "What is 5 plus 7?" } ], "tools": [ { "name": "add_numbers", "description": "Adds two numbers", "parameters": { "type": "object", "properties": { "a": { "type": "number" }, "b": { "type": "number" } }, "required": [ "a", "b" ] } } ] } ``` This is now a **provider API request**. It is no longer the MCP `tools/list` request. This distinction is critical. The Host has crossed from: ``` MCP ``` into: ``` LLM Provider API ``` The LLM receives the user question and the available tool. It reasons that the `add_numbers` tool is appropriate. It generates the arguments: ``` { "a": 5, "b": 7 } ``` This is an important distinction. The Server provided the schema. The LLM generated the actual values. The Server effectively said: ``` a must be a number b must be a number ``` The LLM generates: ``` a = 5 b = 7 ``` The model has therefore created new structured data that matches the schema it was given. The provider returns something conceptually like: ``` { "function_call": { "name": "add_numbers", "arguments": "{\"a\":5,\"b\":7}" } } ``` An extremely important point is that the LLM has **not executed the function**. It has only requested that the Host execute it. The LLM is effectively saying: "I believe the `add_numbers` tool should be called with `a = 5` and `b = 7`." The Host is still responsible for the actual invocation. Now the Host has the LLM's tool decision. But the decision is expressed in the provider's format. The Host needs to turn it back into an MCP request. The Host performs the second translation. It takes the provider's tool call: ``` { "name": "add_numbers", "arguments": "{\"a\":5,\"b\":7}" } ``` and converts it into an MCP `tools/call` request: ``` { "method": "tools/call", "params": { "name": "add_numbers", "arguments": { "a": 5, "b": 7 } }, "id": 2 } ``` The Host has now crossed the protocol boundary again: ``` LLM Provider API | | Translation #2 v MCP / JSON-RPC ``` The MCP Client sends the new request to the Server: ``` { "method": "tools/call", "params": { "name": "add_numbers", "arguments": { "a": 5, "b": 7 } }, "id": 2 } ``` Notice that this is a new JSON-RPC request. The discovery request used: ``` id: 1 ``` The tool invocation uses: ``` id: 2 ``` The two requests are separate operations. The Server receives the request. It reads: ``` params.name ``` which contains: ``` add_numbers ``` The Server looks up that name in its registry. ``` js const tool = registry.get("add_numbers"); ``` The Server now has access to the tool definition and its handler. Before executing anything, the Server validates the arguments. The arguments are: ``` { "a": 5, "b": 7 } ``` The Server validates them against the tool's schema. ``` z.object({ a: z.number(), b: z.number() }); ``` The validation succeeds: ``` a = 5 ✓ number b = 7 ✓ number ``` This step is extremely important. The LLM generated the arguments. But the MCP Server should still validate them. The model should not be treated as a trusted source of executable input. The schema acts as a contract between the tool definition and the actual execution. Only now does the actual computation happen. The Server executes: ``` 5 + 7 = 12 ``` The handler might look like: ``` async function addNumbers(args: { a: number; b: number; }) { return args.a + args.b; } ``` The Server then packages the result into an MCP-compatible result: ``` { "content": [ { "type": "text", "text": "Result: 12" } ] } ``` This is the first point in the lifecycle where the actual tool computation happens. Everything before this point was discovery, translation, decision-making, validation, or orchestration. The Server sends the result back to the Client: ``` { "id": 2, "result": { "content": [ { "type": "text", "text": "Result: 12" } ] } } ``` This is again MCP/JSON-RPC. The result has not yet been given back to the LLM. The Client receives it first. The tool has now executed successfully. The result is: ``` Result: 12 ``` But the user did not ask to see raw tool output. The user asked a natural-language question. The Host therefore needs the LLM to turn the structured tool result into a final response. The MCP Client receives: ``` Result: 12 ``` and passes the result back to the Host. The Host now has the output of the MCP tool. The Host performs the third and final translation. It converts: ``` MCP Tool Result LLM Provider Tool Result MCP Result | | Translation #3 v Provider Tool Output { "role": "tool", "name": "add_numbers", "content": "Result: 12" } ``` The exact structure depends on the LLM provider. The important concept is that the Host again acts as the bridge. The LLM now receives the conversation context together with the tool result. ``` User: What is 5 plus 7? Tool: Result: 12 ``` The LLM can now generate a natural-language response: ``` 5 plus 7 is 12. ``` The tool provided the computation. The LLM provides the conversational response. Finally, the Host returns: ``` 5 plus 7 is 12. ``` The user sees: **5 plus 7 is 12.** The complete lifecycle is finished. The easiest way to understand the entire architecture is to focus on the three translations. The Host converts: ``` MCP Tool Schema ↓ LLM Provider Tool Schema ``` This allows the LLM to understand which tools are available and what arguments they accept. ``` LLM Provider Tool Call ↓ MCP tools/call ``` This takes the LLM's decision and turns it into an actual MCP tool invocation. ``` MCP Tool Result ↓ LLM Provider Tool Result ``` This allows the LLM to see the result of the tool execution and formulate the final response. We can now compress the entire architecture into one diagram: ``` USER | | "What is 5 + 7?" v HOST | | Start discovery v CLIENT | | tools/list v SERVER | | Read tool registry | Return tool definitions v CLIENT | v HOST | | Translation #1 | MCP schema -> Provider schema v LLM | | Decide: | add_numbers(a=5,b=7) v HOST | | Translation #2 | Provider call -> MCP tools/call v CLIENT | | tools/call v SERVER | | Find tool | Validate arguments | Execute handler | | 5 + 7 = 12 v CLIENT | v HOST | | Translation #3 | MCP result -> Provider result v LLM | | "5 plus 7 is 12." v HOST | v USER ``` Here is the entire process in one place. **1. User** The user asks: ``` "What is 5 plus 7?" ``` **2. Host** The Host starts the agent and initiates tool discovery. **3. Client** The MCP Client sends: ``` { "method": "tools/list", "id": 1 } ``` **4. Server** The MCP Server reads its tool registry and prepares the available tool definitions. **5. Server** The Server responds: ``` { "id": 1, "result": { "tools": [ { "name": "add_numbers", "description": "Adds two numbers", "inputSchema": {} } ] } } ``` **6. Client** The Client passes the tool definitions back to the Host. **7. Host — Translation #1** ``` MCP tool schema ↓ Provider tool schema ``` **8. Host** The Host sends the user's prompt and the translated tools to the LLM provider. **9. LLM** The LLM determines that `add_numbers` is appropriate and generates: ``` { "a": 5, "b": 7 } ``` **10. LLM** The LLM returns its provider-specific tool/function call. **11. Host — Translation #2** The Host converts the provider tool call into an MCP `tools/call`. **12. Client** The Client sends: ``` { "method": "tools/call", "params": { "name": "add_numbers", "arguments": { "a": 5, "b": 7 } }, "id": 2 } ``` **13. Server** The Server looks up `add_numbers` in its registry. **14. Server** The Server validates: ``` a = 5 ✓ b = 7 ✓ ``` **15. Server** The Server executes the handler: ``` 5 + 7 = 12 ``` **16. Server** The Server returns the MCP result. **17. Client** The Client receives the MCP result and passes it to the Host. **18. Host — Translation #3** ``` MCP result ↓ Provider tool result ``` and sends it to the LLM. **19. LLM** ``` "5 plus 7 is 12." ``` **20. User** ``` 5 plus 7 is 12. ``` The following simplified TypeScript code demonstrates the main architectural boundaries. ``` js import { z } from "zod"; // ========================================== // 1. TOOL DEFINITION // ========================================== const addNumbersSchema = z.object({ a: z.number(), b: z.number(), }); type AddNumbersArgs = z.infer; const tool = { name: "add_numbers", description: "Adds two numbers", inputSchema: { type: "object", properties: { a: { type: "number" }, b: { type: "number" }, }, required: ["a", "b"], }, handler: async (args: AddNumbersArgs) => { return args.a + args.b; }, }; // ========================================== // 2. MCP: tools/list // ========================================== function listTools() { return { tools: [ { name: tool.name, description: tool.description, inputSchema: tool.inputSchema, }, ], }; } // ========================================== // 3. TRANSLATION #1 // // MCP schema // ↓ // Provider schema // ========================================== function toProviderTool(mcpTool: any) { return { name: mcpTool.name, description: mcpTool.description, parameters: mcpTool.inputSchema, }; } // ========================================== // 4. TRANSLATION #2 // // Provider function call // ↓ // MCP tools/call // ========================================== function toMcpToolCall(functionCall: any) { return { method: "tools/call", params: { name: functionCall.name, arguments: JSON.parse( functionCall.arguments ), }, id: 2, }; } // ========================================== // 5. SERVER EXECUTION // ========================================== async function executeTool( name: string, arguments_: unknown ) { if (name !== tool.name) { throw new Error( `Unknown tool: ${name}` ); } // Server-side validation const args = addNumbersSchema.parse(arguments_); // Actual computation const result = await tool.handler(args); return { content: [ { type: "text", text: `Result: ${result}`, }, ], }; } // ========================================== // 6. TRANSLATION #3 // // MCP result // ↓ // Provider tool result // ========================================== function toProviderToolResult( mcpResult: any ) { return { role: "tool", content: mcpResult.content, }; } ``` The same architecture can be represented in Python. ``` python from typing import Any import json # ========================================== # 1. TOOL DEFINITION # ========================================== def add_numbers(a: float, b: float) -> float: return a + b TOOL = { "name": "add_numbers", "description": "Adds two numbers", "inputSchema": { "type": "object", "properties": { "a": { "type": "number" }, "b": { "type": "number" } }, "required": [ "a", "b" ] } } # ========================================== # 2. MCP: tools/list # ========================================== def list_tools() -> dict: return { "tools": [ { "name": TOOL["name"], "description": TOOL["description"], "inputSchema": TOOL["inputSchema"] } ] } # ========================================== # 3. TRANSLATION #1 # # MCP schema # ↓ # Provider schema # ========================================== def to_provider_tool( mcp_tool: dict ) -> dict: return { "name": mcp_tool["name"], "description": mcp_tool["description"], "parameters": mcp_tool["inputSchema"] } # ========================================== # 4. TRANSLATION #2 # # Provider function call # ↓ # MCP tools/call # ========================================== def to_mcp_call( function_call: dict ) -> dict: arguments = json.loads( function_call["arguments"] ) return { "method": "tools/call", "params": { "name": function_call["name"], "arguments": arguments }, "id": 2 } # ========================================== # 5. SERVER EXECUTION # ========================================== def execute_tool( name: str, arguments: dict ) -> dict: if name != "add_numbers": raise ValueError( f"Unknown tool: {name}" ) # Server-side validation if not isinstance( arguments.get("a"), (int, float) ): raise ValueError( "a must be a number" ) if not isinstance( arguments.get("b"), (int, float) ): raise ValueError( "b must be a number" ) # Actual computation result = add_numbers( arguments["a"], arguments["b"] ) return { "content": [ { "type": "text", "text": f"Result: {result}" } ] } # ========================================== # 6. TRANSLATION #3 # # MCP result # ↓ # Provider tool result # ========================================== def to_provider_result( mcp_result: dict ) -> dict: return { "role": "tool", "content": mcp_result["content"] } ``` We can combine the concepts into a simplified Host implementation. ``` async function runAgent( userPrompt: string ) { // ====================================== // PHASE 1: DISCOVERY // ====================================== const mcpResponse = await mcpClient.request({ method: "tools/list", id: 1, }); const mcpTools = mcpResponse.result.tools; // ====================================== // TRANSLATION #1 // ====================================== const providerTools = mcpTools.map( toProviderTool ); // ====================================== // PHASE 2: ASK THE LLM // ====================================== const llmResponse = await llmProvider.chat({ messages: [ { role: "user", content: userPrompt, }, ], tools: providerTools, }); // ====================================== // LLM SELECTED A TOOL // ====================================== const functionCall = llmResponse.function_call; // ====================================== // TRANSLATION #2 // ====================================== const mcpCall = toMcpToolCall( functionCall ); // ====================================== // PHASE 3: EXECUTE THROUGH MCP // ====================================== const toolResult = await mcpClient.request( mcpCall ); // ====================================== // TRANSLATION #3 // ====================================== const providerResult = toProviderToolResult( toolResult ); // ====================================== // FINAL LLM RESPONSE // ====================================== const finalResponse = await llmProvider.chat({ messages: [ { role: "user", content: userPrompt, }, { role: "tool", content: providerResult.content, }, ], }); return finalResponse; } ``` Understanding this flow changes how we think about MCP. MCP is not simply: "A way for an LLM to call a function." Instead, MCP provides a standardized interface through which an AI application can discover and invoke tools. The Host connects that standardized interface to an LLM provider. This creates a separation of responsibilities. The MCP Server does not need to know which LLM is being used. The LLM does not need to know how the MCP Server internally implements its tools. The Host coordinates everything. The architecture can therefore look like: ``` ┌─────────────────┐ │ MCP SERVER │ │ │ │ add_numbers │ │ search │ │ database │ │ APIs │ └────────┬────────┘ │ MCP │ ▼ ┌─────────────────┐ │ HOST │ │ │ │ Discovery │ │ Translation │ │ Orchestration │ └────────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ LLM A LLM B LLM C ``` The MCP Server exposes tools. The Host translates and orchestrates. The LLM decides which tool to use. The Server validates and executes. The LLM finally turns the result into natural language. This is probably the most important takeaway from this entire flow. It is tempting to think about the architecture like this: ``` User ↓ MCP ↓ LLM ``` But a more accurate representation is: ``` ┌─────────────┐ │ USER │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ HOST │ └──────┬──────┘ │ ┌─────────────┴─────────────┐ │ │ ▼ ▼ MCP Protocol Provider API │ │ ▼ ▼ CLIENT LLM │ ▼ SERVER │ ▼ TOOLS ``` The Host is therefore an **adapter and orchestrator** between the two protocol worlds. Another important distinction is responsibility. The MCP Server says: "Here is a tool I expose, its description, and the arguments it accepts." The LLM decides: "This tool is appropriate for the user's question, and I want to call it with these arguments." The Host coordinates the process. This can be summarized as: | Component | Responsibility | |---|---| | User | Provides intent | | Host | Orchestrates the lifecycle | | MCP Client | Communicates with MCP Servers | | MCP Server | Exposes and executes tools | | Tool Registry | Stores tool definitions and handlers | | LLM | Decides whether and how to use a tool | | Schema | Defines valid arguments | | Tool Handler | Performs the actual operation | One of the most important details in this architecture is validation. ``` { "a": 5, "b": 7 } ``` But the Server should not simply assume those arguments are valid. The Server validates them against its own schema. ``` js const schema = z.object({ a: z.number(), b: z.number(), }); const validatedArgs = schema.parse(arguments); ``` This creates an important boundary: ``` LLM-generated data | v Server validation | | valid v Tool execution ``` The LLM is probabilistic. The tool execution environment should remain deterministic and controlled. The schema therefore becomes an important contract between model-generated arguments and real-world execution. If there is only one diagram to remember from this entire article, it should be this: ``` USER │ │ "What is 5 + 7?" ▼ HOST │ │ MCP discovery ▼ CLIENT │ │ tools/list ▼ SERVER │ │ Tool registry │ Tool definitions ▼ CLIENT │ ▼ HOST │ │ Translation #1 │ │ MCP schema │ ↓ │ Provider schema ▼ LLM │ │ Tool decision │ add_numbers │ a = 5 │ b = 7 ▼ HOST │ │ Translation #2 │ │ Provider tool call │ ↓ │ MCP tools/call ▼ CLIENT │ │ tools/call ▼ SERVER │ │ Find tool │ Validate arguments │ Execute handler │ │ 5 + 7 = 12 ▼ CLIENT │ ▼ HOST │ │ Translation #3 │ │ MCP result │ ↓ │ Provider tool result ▼ LLM │ │ "5 plus 7 is 12." ▼ HOST │ ▼ USER ``` The entire lifecycle can therefore be summarized in one sentence: **Discover → Translate → Decide → Translate → Execute → Translate → Respond.** Or, even more simply: **The Host is the bridge between MCP and the LLM provider.** MCP standardizes how the Host discovers and invokes tools. The LLM provider API defines how the Host communicates with the model. The Host connects these two worlds through **three translations**: ``` 1. MCP Tool Schema ↓ Provider Tool Schema 2. Provider Tool Call ↓ MCP tools/call 3. MCP Tool Result ↓ Provider Tool Result ``` And that is the real story behind a seemingly simple question such as: Behind that one sentence is an entire lifecycle of **discovery, protocol messages, schema translation, model decision-making, argument generation, validation, tool execution, result translation, and final natural-language generation.** That is the MCP tool-call lifecycle. **Two protocols. Three translations. One complete request.**