Do provider native tools still work through an LLM gateway?

One question showed up on Reddit five times in a single day, across r/aiagents, r/n8n, r/AiAutomations and two others, with almost identical wording: if I use an AI API through a third party provider, will I have access to the same tools the model API has. Some versions named the gateways directly and asked about Gemini grounding search and URL context, OpenAI web search and file search, and Anthropic web fetch and MCP.

Fair question, and the honest answer has three parts: mostly yes, it depends on the gateway, and here is how to check.

Why the answer is not a flat yes

Gateways sit in the request path, and there are two philosophies for what to do there.

Normalize. Translate every request into one internal schema, then translate it back out per provider. Clean, portable, and it silently drops anything the schema does not model. Provider specific extras are the first casualty.

Proxy and extend. Keep the provider request shape, pass through parameters the gateway does not recognize, and add features on top explicitly. Native capabilities keep working, and the gateway is responsible for documenting which ones it supports first class.

We build the second way, because the alternative means every new provider feature is blocked on us shipping schema support. When a lab ships a new parameter on a Tuesday, you should be able to use it on Tuesday.

That said, "it passes through" is not good enough for anything you bill for. Some features need the gateway to understand them: streamed tool events, server side tool billing, cache breakpoints, reasoning token accounting. Those we support as documented features.

Feature by feature

Web search. Provider hosted search runs on the provider side and is billed separately from tokens. It works through a gateway that supports it deliberately. See web search. Compare with the provider's own reference, for example OpenAI's web search tool and Gemini grounding, so you know what behavior to expect per model.

Grounding and URL context. Google's grounding and URL context are request parameters on the Gemini API. They pass through, and results come back in the response as they would direct. Test one request per model before rolling out, since availability differs across Gemini variants.

Function calling and tool use. Fully supported, and the place where provider differences bite hardest is formatting rather than availability. The same model can be reliable at JSON on one host and shaky on another, which is why we ship structured outputs and tool call analytics. Background in structured outputs across LLM providers.

MCP. This is the case where a gateway is better than direct. You get one place to register servers, per user credentials, and visibility into what agents call: MCP gateway, server management, user keys, and MCP analytics. The protocol itself is documented at modelcontextprotocol.io, and we compared the options in MCP gateway comparison 2026.

Prompt caching. Works, and matters more than most native features because agent loops resend the same prefix constantly. Use auto caching for the automatic case and manual caching or Messages API caching when you want explicit breakpoints.

Reasoning tokens. Passed through and accounted for, including effort controls where the provider exposes them: reasoning. Worth watching in analytics, since reasoning heavy models can change your cost profile without changing your prompt.

Streaming. Supported, including tool call deltas: streaming. This is a good gateway test, because a proxy that buffers responses breaks agent UX even though every response is technically correct.

Vision, PDFs, audio, images. Image understanding, PDF support, image generation, and speech and transcription endpoints in the API reference.

Anthropic and OpenAI native shapes. If your code already speaks the Messages API or the Responses API, you do not have to rewrite it. Both are supported directly, see messages create and responses create, plus the Anthropic agent SDK integration.

What you gain that direct calls do not give you

The Reddit question frames a gateway as a possible tax on capability. In practice the trade runs the other way for anything past a prototype.

Failover across providers with fallback policies. Cost attribution per team and per customer with request metadata and cost tracking. Hard spend ceilings per key with API limits. One catalog of hundreds of models with supported models. Governance through approved models, RBAC, and SSO. Region control with EU routing. And your own provider accounts if you want them, through bring your own keys.

That is the same week's other recurring theme, incidentally. One engineer described setting up an LLM gateway for 2500 employees while testing Claude Code, Codex, OpenCode and a hundred other tools. At that scale the native tool question stops being the hard part. Who may use which model, and who pays, is the hard part.

How to verify in ten minutes

Do not take a vendor's word, including ours. Run this:

1. Send the same request direct to the provider and through the gateway, with the native tool enabled, and diff the responses.
2. Check that the tool executed, rather than the model narrating that it would.
3. Stream it and confirm tool call deltas arrive incrementally.
4. Send an unknown parameter and confirm it is passed through rather than stripped or rejected.
5. Send the same long prefix twice and confirm the second call reports a cache hit.
6. Look at the logs entry and confirm token counts and cost line up with what the provider billed.

If all six pass, native capability is not your constraint. Setup guides for the common clients are in the docs: Claude Code, Cursor, Cline, Roo Code, OpenAI Codex, OpenCode, and n8n. Start with the quickstart.