ADK bug — LiteLlm: native tools silently dropped when routing through a proxy gateway

[RayaneKADEM]

🔴 Required Information

Is your feature request related to a specific problem?

When using ADK's LiteLlm integration through a proxy gateway, native/built-in tools (tools without function_declarations, such as Google Search) are silently dropped — they never reach the gateway in the request body.

This affects at least two providers:

• Vertex AI (Gemini models) via an OpenAI-compatible proxy — native tools are not serialized into the request; workaround via LiteLlm subclass confirmed working
• OpenAI (GPT-4o) — same issue; a model-specific extra_body argument was suggested as a workaround but could not be made to work

There is no unified, provider-agnostic mechanism to forward native tools through a proxy. The failure is silent — no error is raised, the tools are simply absent from the outgoing request.

Describe the Solution You'd Like

A unified, provider-agnostic way to use native/built-in tools through a proxy gateway — without requiring the caller to manually construct model-specific extra_body arguments. The exact implementation is left to the ADK team's discretion.

Impact on your work

Any ADK agent using native tools (e.g. Google Search) through a gateway cannot rely on LiteLlm out of the box. We had to subclass LiteLlm and override generate_content_async to manually extract and inject native tools:

config = llm_request.config
if config and config.tools:
 builtin_tools = [t for t in config.tools if not t.function_declarations]
 if builtin_tools:
 func_tools = [
 _function_declaration_to_tool_param(fd)
 for t in config.tools
 if t.function_declarations
 for fd in t.function_declarations
 ]
 builtin_json = [t.model_dump(by_alias=True, exclude_none=True) for t in builtin_tools]
 config.tools = None # prevent LiteLLM from re-adding as duplicates
 extra_body = {"tools": func_tools + builtin_json}

This is brittle, provider-specific, and should not be necessary.

Willingness to contribute

No — happy to provide more context or test a fix if the team proposes one.

---

🟡 Recommended Information

Describe Alternatives You've Considered

• Model-specific extra_body argument — works for a single provider but requires a different implementation per model (Gemini vs GPT-4o), not portable.
• Subclassing LiteLlm — current workaround, confirmed working but duplicates internal logic and breaks on any upstream refactor of generate_content_async.

Proposed API / Implementation

N/A — we have not investigated the internals of src/google/adk/models/lite_llm.py to propose a specific fix. The issue is reported from the caller's perspective.

Additional Context

Related constraint: ADK does not allow mixing native tools and AgentTool sub-agents in the same agent. This applies to all native tools (not just Google Search) — any built-in tool must be wrapped in a dedicated sub-agent when AgentTool entries are present. Fixing native tool forwarding through the gateway would make this constraint less painful in practice.

[surajksharma07]

@RayaneKADEM traced this to _get_completion_inputs in lite_llm.py (~line 2026), where the entire tool-conversion block is gated on tools[0].function_declarations being truthy, so any Tool without function declarations (like google_search) is silently dropped before the request even reaches LiteLLM.

Worth trying: replace that block with a loop that collects function tools as usual and also serializes native tools via tool.model_dump(by_alias=True, exclude_none=True) into the same combined list — the workaround you already have is essentially the right idea applied at the right level.

Could you give it a solid test across both providers on your setup (Vertex AI proxy + OpenAI) and confirm it holds up before raising a PR? Provider-specific serialization differences may surface during testing, so worth checking both carefully.

Let us know how it goes — happy to help review once you've had a chance to verify end-to-end!

[surajksharma07]

Going ahead and closing this out since it's been a few weeks without a follow-up.

Worth noting for anyone landing here: this isn't fixed in the current release. _get_completion_inputs in lite_llm.py still only checks tools[0].function_declarations, so native tools through a proxy are still silently dropped in v2.4.0.
The extra_body workaround from the issue description (and the fix approach we outlined) should still get you unblocked in the meantime.

Feel free to reopen or tag us if you get a chance to test the fix, or if this is still biting you — happy to pick it back up!

[vup903]

Hi @surajksharma07! Since this got reopened and the original reporter hasn't had a chance to test the fix, I'd like to pick it up.

I checked current main and the gate is still there: in _get_completion_inputs (the "Convert tool declarations" block in lite_llm.py), everything hinges on tools[0].function_declarations, so a Tool with only native tools ends up as tools=None. One extra thing I noticed while reading it: any Tool past index 0 is ignored too, so I'd cover that in the same fix.

My plan is basically your outline: loop over all config.tools, keep function declarations on the existing _function_declaration_to_tool_param path, and serialize native tools with model_dump(by_alias=True, exclude_none=True) into the same list. Unit tests would cover native-only, mixed, multiple Tool objects, and a no-tools regression case, asserting what actually reaches litellm.completion.

For end-to-end testing: I can run a local litellm proxy and check the request body on the OpenAI path. I don't have a Vertex setup though, so that side would be wire-shape tests against a mocked OpenAI-compatible backend — would be great if someone with a real Vertex proxy can double-check during review.

One thing I'd like your read on before starting: for providers that reject native tool schemas, should mixed native + function tools still send both, or drop the native ones with a warning? Happy to go either way.

(For context, I'm a CS master's student at Georgia Tech.)

[surajksharma07]

@vup903 Welcome, and thanks for picking this up! Re-checked the current code and your read is exactly right — still unpatched through v2.5.0/main, same tools[0].function_declarations gate, now at lite_llm.py lines 2377–2387.

The "any Tool past index 0 is ignored too" catch is correct and worth folding into the same fix — the list comprehension never touches config.tools[1:] at all, so that's really the root bug (only tools[0]'s function declarations ever survive).
Native-tool dropping is just the most common way people hit it.

One more spot with the identical pattern if you want to cover it in the same PR: _build_request_log (~line 2461) has the same tools[0]-only slice.
It's log-string-only so it doesn't affect what's actually sent, just what gets debug-logged for multi-tool requests — but worth fixing for consistency.

On your design question: lean towards always sending both function and native tools rather than dropping natives with a warning.
The reporter's own extra_body workaround sent them unconditionally and worked fine on both Vertex and OpenAI paths in their testing, and ADK pre-emptively guessing provider support feels out of scope — let the proxy/provider reject if a given schema isn't supported, same as any other unsupported-parameter case.

No PR is linked to this issue yet, so you're clear to open one.
Go ahead with the plan as outlined and ping if you want a second pair of eyes on the Vertex-side wire shape once you've got the OpenAI path working!

[vup903]

@surajksharma07 Opened #6416 with the fix. Covered all three spots including the _build_request_log slice you flagged, and went with always sending both function and native tools per your call. New unit tests pass (native-only, mixed, tools-beyond-index-0, no-tools regression) plus the existing suite: 345 passed. I verified the OpenAI wire shape against a local litellm proxy; I'd love your second pair of eyes on the Vertex-side shape when you get a chance, since I can't test that path directly. Thanks for the quick, detailed pointers!