AGENTIC COMMONSAI industry briefings

繁中EN

TAGAgent FrameworkPUBLISHED 2026-10-06

All English articlesAgent Framework

One Tool, Six Frameworks: Who Owns the Schema Translation

You ship an agent with working tool calling. Then you swap the model behind it and every tool call starts failing. Your tool definition never changed — the wire format did. That’s the concrete problem OpenRouter’s October 2, 2026 comparison of six agent frameworks digs into, and it’s worth reading even if you’re happy with your current stack, because it forces a decision most teams make implicitly: where does schema translation live?

The formats genuinely don’t interchange

All providers agree on what a tool is — a name, a description, a JSON Schema for parameters. The disagreement starts the moment you put it on the wire. OpenAI’s Chat Completions wraps everything in a function object and returns tool_calls with arguments as a JSON-encoded string. Anthropic’s Messages API uses a flatter input_schema and returns a tool_use content block with arguments already parsed. Gemini nests definitions under function_declarations and returns a functionCall part inside the response content. One tool, three request shapes, three response shapes.

Open-weight models add a nastier case: a model not trained to emit a tool-calling format can only produce calls as text, and the serving layer’s prompt-and-parse handling fails differently from a native format.

Three places to put the translation

The comparison frames the options cleanly. You can own the per-provider mapping in your application — full control, ongoing maintenance burden. You can push it into the framework. Or you can normalize at the API layer: a gateway accepts one format and translates on the way to each provider. The six frameworks differ mainly in how much of the middle option they take on.

LangChain and LangGraph translate one tool definition per provider through their chat model integrations, so the same agent code runs across OpenAI, Anthropic, and Google models. CrewAI delegates entirely to the client it routes to — native SDKs for the big providers, LiteLLM for everything else. The OpenAI Agents SDK and Google ADK are built around their own vendor’s format, with cross-provider support running through OpenAI-compatible endpoints or beta LiteLLM adapters. The Claude Agent SDK has no cross-provider translation at all — it targets Anthropic’s native tool_use format, which is fine until it isn’t. Microsoft Agent Framework, positioned as the AutoGen and Semantic Kernel successor, hands translation to whichever model connector you configure.

Notice the pattern: single-vendor SDKs give you the best experience on that vendor’s models and a compatibility layer everywhere else. Framework-level translation is real, but its quality depends on the specific provider integration — OpenRouter’s own advice is to test the exact model you plan to ship on, not just the adapter.

What this changes for how you build

The practical payoff of gateway-level normalization is that switching models becomes a change to the model string. OpenRouter accepts an OpenAI-style tools array and returns a standard tool_calls response for every tool-capable model. On requests that include tools, Auto Exacto reorders providers by throughput, tool-calling success rate, and benchmark data — and the Tool Call Error Rate metric behind it is visible on each model’s Performance tab, so you can see failure rates before you commit.

This pairs naturally with the discipline of treating every model swap as a schema migration worth regression testing — I wrote about that approach in Treat Every Prompt Edit Like a Schema Migration. Tool-call breakage on a model change is exactly the failure class those regression suites exist to catch.

A grounded takeaway

You don’t need to change your framework today. But before your next model swap, ask one question: which layer is translating my tool schemas, and have I tested it on the target model? A framework listing a provider adapter and a model genuinely supporting native tool calling are two different things — and as OpenRouter puts it, the gap between them is where the surprises come from. The supplied source covers each framework’s MCP support in depth; the full comparison tables are worth a read if MCP is in your stack.

Sources

AGENTIC COMMONSOperated by PHLEGON LABS
SHAREXEMAIL
Support us

Related reading

  1. Cheap-First Routing for Support Bots: What Your App Owns vs. What the Gateway Handles

    OpenRouter's new tutorial maps three app-side routing patterns for sending easy support tickets to cheap models and escalating the rest.

    OpenRouter

  2. Stripe Buys OpenRouter: the AI Routing Layer Joins Payments

    Stripe is acquiring AI model router OpenRouter — reported at $7.5 billion — pulling the neutral layer that moves 10 trillion tokens a day into payments.

    OpenRouter

  3. Provider-Run Sandboxes Are Becoming Part of the API: How OpenRouter's Shell Tool Fits In

    OpenRouter compares its shell and bash tools with OpenAI, Anthropic, and Google sandboxed code execution across runtime, isolation, persistence, and cost.

    OpenRouter