Function Calling 与 MCP 清晰图解

Function calling & MCP for LLMs, clearly explained:

Before MCP, tool access ran entirely on function calling, and every integration was wired by hand.

MCP standardized that integration layer, but the model still emits the same tool call underneath it.

The visual below explains how each one works.

In function calling, the model never executes anything itself:

• The model receives a prompt and the available function definitions. - It decides which tool fits and emits a tool call request inside its response. - A procedure on our side parses that request and prepares the actual function call. - A backend service runs the tool and returns the output to the model.

All of this lives in our own stack.

• We host the tool - We write the logic that maps a tool call request to a function and its parameters - And we execute it

So function calling just decides what to run, and the integration around it is left entirely to the engineer.

MCP standardizes that integration.

Instead of hand-wiring each tool, MCP:

• Defines one protocol for declaring, hosting, and exposing tools. - Makes tools discoverable, with schemas the client can read directly. - Requires approval before a tool runs. - Separates the side that implements a tool from the side that consumes it.

Once an MCP server is integrated, not a single line of Python is written to connect its tools.

The server is added once, and everything past that point follows the protocol handled by the MCP client and the model.

• They identify the MCP tool. - They prepare the input arguments. - They invoke the tool through the server. - They use the returned output to generate the response.

Function calling and MCP are not competing approaches but rather two stages of the same tool call.

• Function calling involves the model picking the tool. - MCP is everything that happens after picking it, like locating the tool, checking its schema, getting approval, and running it.

When an agent decides "I need to search the web" through function calling, the decision routes through MCP, which selects from the registered web search tools, invokes the right one, and returns the result.

Of course, there is a cost associated with that convenience.

Integrating an MCP server loads every one of its tool definitions into context. A heavy server can spend most of the window on tool schemas before the agent runs a single call.

I wrote a detailed walkthrough (with code) on fixing exactly that, where tool loading is scoped down to the groups actually in use, individual tools are selected instead of pulling the whole server, and context usage drops 80-90% on a live setup.

Read it below.