Tool Use, Function Calling, MCP: The Production LLM Integration Stack (2026)

**The pattern:** Declare tools as JSON-schema descriptors. Pass them with the model call. Parse `tool_calls` from the response. Execute. Return tool results in the next turn. Loop until the model returns a final assistant message without tool calls.

**OpenAI's flavor:** Per OpenAI's function calling docs at platform.openai.com, tools are declared in `tools=[{type:'function', function:{name, description, parameters}}]`. Response has `message.tool_calls[]` with `id`, `function.name`, `function.arguments` (JSON string). Tool results go back as messages with `role:'tool'` and matching `tool_call_id`.

**Anthropic's flavor:** Per Anthropic's tool use guide at docs.anthropic.com, tools are declared in `tools=[{name, description, input_schema}]`. Response content array contains `tool_use` blocks with `id`, `name`, `input` (already-parsed object). Tool results go back as `tool_result` content blocks with matching `tool_use_id`.

**Google's flavor:** Per Google's Gemini function calling docs at ai.google.dev, tools are declared as `tools=[{functionDeclarations:[...]}]`. Response has `parts[].functionCall` with `name`, `args`. Tool results go back as `parts[].functionResponse`.

**The reality:** Schemas differ. Argument shapes differ. Naming conventions differ. The mental model is identical; the wire-level code is provider-specific. This is where the next two layers (framework abstractions + MCP) become important.

**Goal:** Write tool definitions once, run against any provider. Frameworks translate between the unified tool definition and each provider's wire format.

**LangChain:** Per LangChain's tools documentation at python.langchain.com, define tools with the `@tool` decorator or `StructuredTool.from_function`. Pydantic-schema-based input validation. Tools are then bindable to any LangChain-compatible model. Strength: ecosystem breadth (hundreds of pre-built integrations). Weakness: abstraction overhead and version churn.

**LlamaIndex:** Per LlamaIndex agents documentation at docs.llamaindex.ai, `FunctionTool.from_defaults` wraps any Python function as a tool with auto-generated schema. Integrates with LlamaIndex's agent framework. Strength: tighter integration with retrieval workflows. Weakness: smaller ecosystem than LangChain.

**Pydantic AI:** Per Pydantic AI documentation at ai.pydantic.dev, Pydantic-first agent framework. Tools are typed Pydantic functions. Type safety guaranteed by the runtime. Strength: type-safety + clean Pydantic ergonomics. Weakness: newer, smaller ecosystem.

**The choice:** LangChain for breadth (you'll find an integration), Pydantic AI for type safety (you'll catch errors at runtime cleanly), LlamaIndex if your stack is already RAG-heavy.

**The problem MCP solves:** Tools are written once but bound to a specific framework + specific provider. A tool that queries your PostgreSQL database for the OpenAI API isn't reusable when you switch to Anthropic, switch to a different framework, or expose the same tool to a desktop AI app.

**The pattern:** Per the Model Context Protocol specification at modelcontextprotocol.io, MCP servers expose tools, resources, and prompts via a standardized JSON-RPC protocol. MCP clients (LLM hosts) discover what's available and consume it uniformly. The server can be a local stdio process or a remote HTTP-streaming endpoint.

**Why it's becoming dominant:** The MCP servers reference repository at github.com/modelcontextprotocol/servers already has 100+ first-party and community MCP servers (Postgres, Slack, GitHub, Google Drive, filesystem, etc.). Building tools as MCP servers means they work in Claude Desktop, Cursor, Cline, and any other MCP-aware host without porting.

**Production caveats:** MCP is still maturing. Authentication patterns are evolving. Multi-user authorization is less mature than single-user (desktop client). For production HTTP-streaming MCP, the MCP official documentation on transports is essential reading.

**The strategic move:** Build tools as MCP servers by default. Wrap them in framework code (LangChain/LlamaIndex/Pydantic AI) when you need orchestration. Talk to provider APIs directly only for performance-critical paths or features that frameworks don't yet abstract.

**Failure 1 — Bad tool arguments.** The model produces tool arguments that don't match the schema (missing required field, wrong type, nonsense value). Mitigation: schema validation before execution + structured error message back to the model: 'Argument X must be Y. Retry.' Per Anthropic's tool use guide, surfacing schema errors back to the model lets it self-correct ~70-90% of the time.

**Failure 2 — Tool execution errors.** API returned 500. Database timeout. Filesystem permission denied. Mitigation: catch + format the error as a tool result, not a runtime exception. Let the model decide whether to retry, switch tools, or report failure to the user.

**Failure 3 — Infinite tool loops.** Model keeps calling the same tool because its result doesn't satisfy the model's plan. Mitigation: per-loop iteration cap (typically 10-25). Plus monitoring for repeated identical tool calls — usually a sign of a malformed prompt or hallucinated tool-result interpretation. Per LangChain's agent execution docs, iteration caps are essential production hygiene.

**Failure 4 — Side-effect amplification.** Tool that posts to Slack is called 5 times because the model retries. Tool that charges a credit card is called twice because the first call's response was ambiguous. Mitigation: idempotency keys on side-effecting tools + clear 'this operation has already been performed' tool results when retries happen.

**Failure 5 — Prompt injection via tool results.** A tool returns user-supplied content that contains 'ignore previous instructions...'. Mitigation: per OWASP's LLM Top 10 at owasp.org/www-project-top-10-for-large-language-model-applications, treat tool results as untrusted data. Wrap in clear `<tool_result>` delimiters. Train the prompt to ignore instructions inside tool results.

Single-provider, single-framework tool wiring: Fast initial build. Locked into one provider. Tool re-implementation every time you switch frameworks. Provider outage = system down. No portability to desktop AI clients.
MCP-first + framework abstraction: More upfront setup (~1-2 days extra). Portable across providers + clients. Future-proof against framework churn. Composable with the growing 100+ MCP server ecosystem.