Output_Schema + Tool with structured arg [List of object] causes blank tool input [{}] and infinite loop

[Krajpurohit]

UDescription:
When for an LLMAgent output_schema is defined and the agent has a tool with at least one argument typed as a list or object structure, the tool receives blank/empty values for that argument. After that, the agent keeps invoking the same tool repeatedly and appears to run indefinitely.

Steps to Reproduce:
1 Create an Agent
2 Define an output_schema using a Pydantic model
3 Add a tool that accepts at least one structured arg of type list[dict[str, str]]
4 Run the agent with a prompt that should cause it to call the tool with populated values
5 Observe that the tool is invoked with blank/empty values and then continues being called repeatedly instead of the agent completing normally

Expected Behavior:
The agent should construct and pass proper values to the tool argument, execute the tool normally, and then return a final response that conforms to the defined output_schema.

Observed Behavior:
The tool is called with blank/empty values for the structured argument. After that, the agent continues calling the tool repeatedly and does not terminate normally, appearing to enter an infinite loop.

Environment Details:

• ADK Library Version (pip show google-adk): Reproduced across versions 1.23.0 to 1.27.2
• Desktop OS: Windows
• Python Version (python -V): 3.12

Model Information:

• Are you using LiteLLM: No
• Which model is being used: gemini-2.5-flash

Screenshots:

🟡 Optional Information

Regression:
I tested this across multiple ADK versions from 1.23.0 to 1.27.2, and the issue reproduces in all of them. I have not found a version where this works correctly in my setup.

Minimal Reproduction Code:
Please provide a code snippet or a link to a Gist/repo that isolates the issue.

from google.adk.agents.llm_agent import Agent
from dotenv import load_dotenv
from google.adk.tools import ToolContext
from pydantic import BaseModel, Field
import random

load_dotenv()

class AgentResponse(BaseModel):
    """Structured agent output with the main response separated from facts."""
    response: str = Field(
        description="Friendly user-facing summary of the fruit basket total."
    )
    facts: list[str] | None = Field(
        description="Exactly 3 short and fun fruit facts related to the selected fruits."
    )

def fruits_to_cost(tool_context: ToolContext, fruits: list[dict[str, str]]) -> str:
    """
    Takes a list of fruit dicts and returns a total cost.
    If qty or cost-per-piece is missing, a random value is generated.
    The agent can build this fruit list even from a short user request.
    Example user request: "Make me a colorful tropical fruit basket"
    Example tool input: [{"name": "Mango", "qty": "3", "cost-per-piece": "1.80"}, {"name": "Pineapple"}, {"name": "Kiwi"}]
    Returns: "Estimated basket total for Mango x3 @ $1.80, Pineapple x4 @ $2.10, Kiwi x2 @ $0.90 is $15.00"
    """
    if not fruits:
        return "No fruits were provided, so the total is $0.00"

    basket_lines: list[str] = []
    total_cost = 0.0

    for fruit in fruits:
        name = fruit.get("name", "Unknown Fruit")
        qty = int(fruit.get("qty", str(random.randint(1, 6))))
        cost_per_piece = float(
            fruit.get("cost-per-piece", f"{random.uniform(0.4, 2.5):.2f}")
        )
        line_total = qty * cost_per_piece
        total_cost += line_total
        basket_lines.append(f"{name} x{qty} @ ${cost_per_piece:.2f}")

    return (
        f"Estimated basket total for ( {', '.join(basket_lines)} ) is ${total_cost:.2f}"
    )


root_agent = Agent(
    model='gemini-2.5-flash',
    name='root_agent',
    description=("Dynamic fruit basket cost calculator"),
    instruction=(
        "## Role\n"
        "You are responsible for creating a lively fruit basket estimate. "
        "The user may give only a short request, such as a mood, color, occasion, or just one fruit name. "
        "In that case, infer a suitable fruit basket yourself and call the tool 'fruits_to_cost' with a list of fruit dictionaries. "
        "Each fruit can include 'name', and may optionally include 'qty' and 'cost-per-piece'. "
        "If some values are missing, the tool will generate them dynamically, so do not ask the user for extra details unless the request is truly unclear. "
        "Choose fruits that match the user intent and make the basket feel vivid and practical. "
        "Then return a cheerful summary in 'response' and exactly 3 engaging fruit facts in 'facts'."
    ),
    tools=[fruits_to_cost],
    output_schema=AgentResponse
)

How often has this issue occurred?:

• Always (100%)

[Krajpurohit]

Quick note - It works well if I enable feature JSON_SCHEMA_FOR_FUNC_DECL which is experimental and WIP

[surajksharma07]

@Krajpurohit — you're already on the right track with JSON_SCHEMA_FOR_FUNC_DECL!

The issue is that the legacy schema path strips out value-type info for dict[str, str], so Gemini only ever sees {"type": "object"} with no field constraints — which is why it defaults to sending [{}] and triggers the infinite loop.

Try setting os.environ["ADK_ENABLE_JSON_SCHEMA_FOR_FUNC_DECL"] = "1" before your agent initializes and see if that clears up both the blank args and the loop on your end.

[Krajpurohit]

Thanks @surajksharma07, yes it works well with this feature enabled.

The only issue is that it’s marked as WIP, which makes it unusable for my setup. Is there any other way to enforce function declarations with the correct schema?

I was thinking of patching the tool function declaration in a before-model callback. What do you think?

[surajksharma07]

@Krajpurohit There's actually a simpler drop-in that works today without needing the flag at all: swap list[dict[str, str]] out for list[FruitItem], where FruitItem is a small Pydantic model with your fields (name, qty, cost_per_piece).

The legacy schema path handles list[BaseModel] correctly — it walks model_fields and generates proper field-level constraints, so you get the behavior you're after without touching any flags.

On the callback idea — it's technically doable, but you'd essentially be patching raw tool declarations inside LlmRequest on every model call, which gets fragile pretty quickly and becomes a pain to maintain if ADK internals shift down the line.

Give the Pydantic model swap a shot first and let us know if that works for your setup!

[Krajpurohit]

@surajksharma07 - Unfortunately it rejects the pydentic model

`### SESSION CONTEXT ###
Session ID: 1d6f71e5-6304-47cf-9851-9826830dbba5
User ID: user
Model Version: Gemini-1.5-flash
Target Function: fruits_to_cost
Timestamp: 2026-03-18 19:07:03

TERMINAL LOGS

2026-03-18 19:07:03,007 - DEBUG - core.py:62 - executing <function Connection.stop..close_and_stop at 0x000001BBE629DF80>
2026-03-18 19:07:03,007 - DEBUG - core.py:67 - operation <function Connection.stop..close_and_stop at 0x000001BBE629DF80> completed
2026-03-18 19:07:03,039 - ERROR - adk_web_server.py:1733 - Error in event_generator: Failed to parse the parameter fruits: list[my_agent.agent.FruitItem] of function fruits_to_cost for automatic function calling. Automatic function calling works best with simpler function signature schema, consider manually parsing your function declaration for function fruits_to_cost.

TRACEBACK (MOST RECENT CALL LAST)

File "C:\Users\xxxxxx\Downloads\Learnings\Stream\oaai-streaming-poc.venv\Lib\site-packages\google\adk\tools_automatic_function_calling_util.py", line 368, in from_function_with_options
parameters_json_schema[name] = types.Schema.model_validate(

File "C:\Users\xxxxxxx\Downloads\Learnings\Stream\oaai-streaming-poc.venv\Lib\site-packages\pydantic\main.py", line 716, in model_validate
return cls.pydantic_validator.validate_python(

pydantic_core._pydantic_core.ValidationError: 2 validation errors for Schema
items.$ref
Extra inputs are not permitted [type=extra_forbidden, input_value='#/$defs/FruitItem', input_type=str]
For further information visit https://errors.pydantic.dev/2.12/v/extra_forbidden
$defs
Extra inputs are not permitted [type=extra_forbidden, input_value={'FruitItem': {'properties': {'item': {'title': 'Item', 'type': 'string'}}, 'required': ['item'], 'title': 'FruitItem', 'type': 'object'}}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.12/v/extra_forbidden

SECONDARY TRACEBACK (DIRECT CAUSE)

Traceback (most recent call last):
File "C:\Users\xxxxxxx\Downloads\Learnings\Stream\oaai-streaming-poc.venv\Lib\site-packages\google\adk\cli\adk_web_server.py", line 1705, in event_generator
async for event in agen:
File "C:\Users\xxxxxxx\Downloads\Learnings\Stream\oaai-streaming-poc.venv\Lib\site-packages\google\adk\runners.py", line 632, in run_async
async for event in agen:
File "C:\Users\xxxxxxx\Downloads\Learnings\Stream\oaai-streaming-poc.venv\Lib\site-packages\google\adk\runners.py", line 617, in _run_with_trace
async for event in agen:
File "C:\Users\xxxxxxx\Downloads\Learnings\Stream\oaai-streaming-poc.venv\Lib\site-packages\google\adk\runners.py", line 853, in _exec_with_plugin
async for event in agen:
File "C:\Users\xxxxxx\Downloads\Learnings\Stream\oaai-streaming-poc.venv\Lib\site-packages\google\adk\runners.py", line 606, in execute

SYSTEM ENVIRONMENT

Python: 3.12.7
Platform: Windows (CRLF)
Venv: .venv (Active)
`

[surajksharma07]

@Krajpurohit the list[BaseModel] approach actually hits a second related bug too.

Pydantic's schema for nested models emits $ref/$defs, and the ADK schema converter rejects those as extra fields in types.Schema, so you'd just be trading one problem for another.

The most reliable workaround right now without any flag is to change the parameter to fruits_json: str, parse it inside the tool with json.loads(), and describe the expected JSON shape in the docstring so the model knows what to serialize.

Not the prettiest solution, but it's completely schema-proof across all versions.

That said, JSON_SCHEMA_FOR_FUNC_DECL is really the only clean fix that addresses both issues properly.

Given it's already confirmed working on your end, it might be worth reconsidering as a controlled interim path — at least until a proper upstream fix lands.

[weiguangli-io]

Root Cause Analysis

Traced through the code — this is a two-layer bug in the legacy schema path that surfaces specifically when output_schema + tools with compound args (like list[dict[str, str]]) are combined.

1. dict[str, str] collapses to {"type": "OBJECT"} with no properties

In _function_parameter_parse_util.py → _parse_schema_from_parameter(), the dict origin branch (line ~295-302) handles dict[str, str] by simply returning Schema(type=OBJECT) — it discards the key/value type args entirely. No properties, no additionalProperties, nothing. Gemini sees a bare {"type": "object"} inside the array items and has no idea what fields to populate, so it sends [{}].

The JSON_SCHEMA_FOR_FUNC_DECL path avoids this because it delegates to Pydantic's model_json_schema() which correctly emits additionalProperties: {"type": "string"}.

2. $ref/$defs rejection blocks the Pydantic BaseModel workaround

Swapping to list[FruitItem] where FruitItem is a BaseModel doesn't help either. The fallback path in from_function_with_options() (line ~368) calls types.Schema.model_validate() on the Pydantic-generated JSON schema, but types.Schema has extra='forbid' — so $ref and $defs (emitted by Pydantic for nested models) are rejected as extra fields.

3. Why infinite loop

When output_schema is set alongside tools and can_use_output_schema_with_tools() returns False (non-Vertex, or Gemini < 2.0), _OutputSchemaRequestProcessor injects a set_model_response tool and instructs the model to call it for final output. But the actual user tool keeps getting invoked with empty args → returns useless results → model retries the tool → never gets valid data to form a final response → never calls set_model_response → loop.

Proposed Fix

The cleanest fix is to make JSON_SCHEMA_FOR_FUNC_DECL the default (or at least auto-enable it when compound types like dict[K,V] or nested BaseModels are detected). The legacy _parse_schema_from_parameter path fundamentally can't represent these types correctly within the types.Schema model.

Short of that, a targeted fix in _parse_schema_from_parameter for the dict branch to emit additional_properties with the value type schema would address the immediate dict[str, str] case — though nested BaseModel via $ref/$defs would still be broken.

Happy to submit a PR for either approach if there's alignment on direction.