Pick a stack for your agent and the question "how does the agent call a tool?" has three popular answers. They look interchangeable in marketing copy. They are not interchangeable in practice. The differences show up in deployment, in debugging, and in how easily your customer's IT team can audit what the agent is doing.

This article is the decision tree. What each protocol is good at, what it costs, and which one to pick first.

What each one actually is

MCP — Model Context Protocol

A protocol, not a framework. JSON-RPC over stdio or HTTP. Schema-first: tools declare their inputs/outputs as JSON Schema; agents read the schema and call the tools. Anthropic published the spec in late 2024; OpenAI added MCP support to ChatGPT in 2025; Cursor, Goose, Cline, Zed, n8n, Copilot Studio, and Microsoft followed.

The protocol does three things — list tools, call a tool, return a result. Auth, rate-limits, deployment shape, and tool implementation are all yours. This is a feature for portability and a cost for time-to-first-tool.

ADK — Google's Agent Development Kit

A framework, not just a protocol. Google ships ADK as the official way to build agents on Vertex AI; the framework handles tool registration, planning loops, tracing, and deployment to Google Cloud. Tools are Python or TypeScript functions decorated with type hints; ADK converts them into Gemini-compatible function definitions.

The differentiator is depth of integration with Google services. ADK tools reach BigQuery, Firestore, Spanner, Vertex Search, and the Google Cloud Run runtime without configuration that you would write by hand on any other stack.

The cost: portability. An ADK-only tool runs in ADK. To call it from Claude or ChatGPT you wrap it — either by exposing it as an MCP endpoint (ADK supports this since early 2026) or by re-implementing.

LangChain Tools

A library, not a protocol. LangChain's Tool abstraction is a Python or TypeScript class; agents call instances of it via the framework's routing logic. The big strength is the ecosystem: thousands of pre-built tools, every LLM provider supported, integrations with every vector DB and every API client.

The cost is operational. LangChain agents are heavyweight: a running Python process, the framework's own retries and parsing, a separate observability story. They are fast to prototype, slow to put in production cleanly. The 2025 shift toward LangGraph helped — explicit state machines instead of opaque agent loops — but the framework still carries weight that MCP servers don't.

The decision tree

Question 1: which agent runtime must the tool reach?

Question 2: where does the data live?

Question 3: how much operational weight can you carry?

Which one is winning?

Mid-2026 snapshot:

None of these is a winner-take-all. The right model is: pick the one that fits your primary distribution channel, and use the others as needed.

What's converging

The interesting trend is that the three are converging on MCP as the wire format:

The probable end state for 2027: MCP is the wire protocol everyone speaks; ADK and LangChain become frameworks that emit and consume MCP. The differentiation moves to the framework layer — memory, planning, tracing — not to the tool-call protocol.

This is the same shape as HTTP in the 1990s. Everyone fought over RPC formats (CORBA, SOAP, XML-RPC); HTTP+JSON won; the differentiation moved to frameworks (Rails, Django, Express) that all speak HTTP. MCP is following the same pattern.

Implications for the tool author

If you are shipping a tool today:

  1. Ship MCP first. One protocol, every major runtime. Lowest portability tax.
  2. Add ADK if your customers are Google-stack-heavy. Wrap your MCP tool as an ADK function definition; it's a 30-line file.
  3. Add LangChain if customers ask. The LangChain MCP adapter does most of the work; expose your MCP server and LangChain agents can call it.

If you are shipping an agent (not a tool):

  1. Pick the framework that fits your stack. Vertex AI → ADK. Python-heavy team → LangChain/LangGraph. Custom runtime → roll your own.
  2. Consume MCP tools. Don't lock your agent to one tool framework; the catalog you want to call from is the MCP catalog.

What about OpenAI's function calling, or Anthropic's tool use?

Both predate MCP. Function calling is what the OpenAI Chat Completions API does natively; tool use is what Anthropic's Messages API does natively. Both are wire formats for "the LLM declares it wants to call a tool, the application runs the tool, the result goes back in."

MCP sits one layer up: it standardizes how an external service exposes tools so the agent runtime (Claude Desktop, ChatGPT app, etc.) can discover and call them. Function calling and tool use are still how the LLM expresses intent within a single application; MCP is how applications expose tools to each other.

If you are writing a single-process app calling one model, function calling/tool use is enough. If you are building a tool that other agents will call across processes and runtimes, you need MCP.

The honest summary

Three protocols, three audiences, one converging direction. For most teams building tools in 2026, the answer is "ship MCP, add the others as needed." For teams locked into Google stack, ADK first. For teams writing fast Python prototypes, LangChain.

The mistake to avoid is picking ADK or LangChain as the only target and writing off the rest of the agent ecosystem. That ecosystem speaks MCP, and the ecosystem is bigger than any single framework's user base.