OpenRouter’s guide shows where tool-calling breaks when you switch models

Changing the model behind an AI agent can break its tool calls even when the tool itself has not changed. OpenRouter’s guide compares how six popular frameworks handle provider-specific tool formats, and explains how a gateway can keep an application’s tool interface consistent across supported models.

OpenRouter Watch analysis

What happened

OpenAI, Anthropic and Google use different formats for defining tools and returning tool calls. Frameworks handle that mismatch in different places: LangChain and LangGraph translate through provider integrations, while CrewAI delegates the work to the client it routes to. The OpenAI Agents SDK, Claude Agent SDK and Google ADK are built around one provider’s format; Microsoft Agent Framework delegates translation to its configured model connector.

OpenRouter’s comparison of agent frameworks and tool-calling schemas says its API accepts an OpenAI-style tools array and returns a standard toolcalls response for models that support tool calling. For requests that include tools, its Auto Exacto feature reorders providers by default using throughput, tool-calling success rate and benchmark data. The associated Tool Call Error Rate metric is available on each model’s Performance tab.

Why it matters

Tool calling is what lets an agent ask software to do something, rather than merely describe what it might do. When a project changes model providers, differences in request formats, returned arguments and tool results can mean extra integration work and new failure points.

The guide gives developers a useful map of where that translation sits, and what they take on when they move away from a framework’s native provider. A gateway can hide some of the wiring, but it does not make every model equally capable: support and reliability still vary, and the precise model needs testing.

Our read

This is a genuinely practical guide for developers building agents across providers. Start by checking whether your framework translates schemas for the specific models you plan to use, then test actual tool calls rather than trusting a compatibility label to do the heavy lifting. The comparison comes from a company selling model access, so its account of its own normalisation and routing is worth treating as a product description, not an independent performance verdict. Even so, the central engineering problem is real: one tool definition does not automatically fit every provider.

What to watch

• Whether framework integrations keep pace with changes to provider APIs.
• How tool-call failure rates vary across the models and providers developers actually use.
• Whether gateway-level normalisation reduces migration work without hiding model-specific limitations.

Discussion spark: Should developers put tool-format translation in their agent framework or in a model gateway, where it can cover more providers but adds another layer to trust?

not affiliated with or endorsed by OpenRouter