【LLM・VLM実践学習 #3】LLMへ道具を使わせる — Function Calling・MCP・Agentの違いThis article clarifies the conceptual differences between Function Calling,…

Giving large language models the ability to use external tools has become one of the central concerns in building practical AI applications, because a model on its own is confined to the knowledge fixed during training and cannot query a database, call a live API, or act on data it has never seen. As the third entry in a practical learning series on LLMs and vision-language models, this article sets out to untangle three terms that are frequently conflated: Function Calling, the Model Context Protocol (MCP), and the Agent pattern. The key insight is that these are not competing alternatives but concepts operating at different layers, and confusing them tends to lead to over-engineered or poorly scoped systems.

Function Calling is best understood as a model capability rather than an execution mechanism. When a developer supplies a set of tool definitions, usually described as JSON schemas with names, parameters, and descriptions, the model can decide that a given request warrants a particular tool and emit a structured payload naming the function and its arguments. Crucially, the model does not run anything itself. The surrounding application receives that structured output, executes the actual code, and feeds the result back into the conversation. OpenAI popularized this approach in 2023, and comparable capabilities are now offered by Anthropic, Google, and others. It is a reliable way to turn free-form language into machine-actionable calls, but the developer remains responsible for wiring each tool by hand.

MCP addresses a different problem: how tools and data sources are exposed and discovered in the first place. Introduced by Anthropic as an open standard in late 2024, MCP defines a client-server protocol so that a tool provider can build an MCP server once and have it consumed by any MCP-compatible client. It is sometimes described as a standardized connector, aiming to reduce the combinatorial burden of writing bespoke integrations for every model and every application pairing. Where Function Calling concerns the moment a model chooses a tool, MCP concerns the plumbing that makes tools portable and reusable across ecosystems. Support appears to be growing beyond its origin, with several major vendors indicating adoption, though the standard is still relatively young and evolving.

The Agent pattern sits at a higher, architectural level. An agent typically wraps a model in a loop: it reasons about a goal, selects an action, observes the outcome, and repeats until the task is complete or a stopping condition is met. This iterative structure, often traced to the ReAct approach that interleaves reasoning and acting, is what distinguishes an agent from a single tool call. Agents usually rely on Function Calling as their action mechanism and may draw their tools from MCP servers, while adding planning, memory, and multi-step orchestration. Frameworks such as LangChain and LlamaIndex provide scaffolding for these loops.

Seen together, the relationship becomes clearer. Function Calling is the mechanism by which a model expresses an intent to act, MCP is a protocol for making tools available in a standardized way, and the Agent is a design pattern for autonomous, multi-step behavior built on top of both. They compose rather than exclude one another.

For selection, the practical guidance is to match the layer to the need. If an application requires only a handful of well-defined, single-shot actions, plain Function Calling is often sufficient and easiest to reason about. If tools must be shared across multiple applications or teams, or a growing catalog of integrations is expected, adopting MCP can reduce duplicated integration work. If the task genuinely requires multi-step reasoning, dynamic tool selection, and adaptation to intermediate results, an agentic loop becomes justified, though it also introduces higher latency, cost, and debugging difficulty, so it is worth avoiding when a simpler pattern suffices.

For readers coming from the vision-language side of this series, the same layering applies. A VLM can use Function Calling to trigger tools after interpreting an image, and those tools can equally be exposed through MCP. The broader industry direction is toward standardizing these interfaces so that models, tools, and orchestration logic can evolve independently. Treating these three concepts as distinct layers, rather than interchangeable buzzwords, is likely the most durable way to make design decisions as the tooling landscape continues to shift.