Setting up Gemma 4 as your model in Antigravity and having the agent refuse to call any tools — or worse, generate malformed JSON on every attempt — is one of the more frustrating onboarding experiences with local models. After more than a decade of indie app development with over 50 million cumulative downloads across my apps, I've run into this specific failure mode enough times to map it clearly.
There are three distinct patterns when Gemma 4 tool calls break in Antigravity. Each has a different root cause, and fortunately, each has a fairly direct fix. The goal of this article is not to cover every edge case but to get you to a working setup as quickly as possible.
Why Gemma 4 Struggles with Tool Calling
Before jumping into the three patterns, it helps to understand a few constraints that make Gemma 4 behave differently from cloud models like Gemini Pro or Claude.
Autonomous tool decision-making: Gemma 4 doesn't always infer that it should use a tool. Without an explicit instruction to prioritize tool calls in the system prompt, it tends to fall back on its training data and generate a text response instead. This is different from Gemini 2.5 Pro, which tends to be more aggressive about reaching for tools when they're defined.
JSON schema tolerance: Gemma 4 accepts OpenAI-compatible tool specifications, but it struggles with deeply nested schemas or complex enum conditions. The more elaborate the tool definition, the higher the probability of a malformed output. There is an effective ceiling on schema complexity that you need to stay below.
Local context limits: When running through Ollama or LM Studio, the default context window is often 4,096–8,192 tokens. If your system prompt, tool definitions, and conversation history together exceed that number, the tools array gets silently truncated. The model ends up with no knowledge that tools are available at all, and naturally makes no attempt to call them.
These three constraints map directly to the three failure patterns described below.
Pattern 1: The Agent Ignores Tools and Answers in Plain Text
Symptom: Antigravity's agent generates a normal text message in response to your query, without ever attempting to invoke a tool — even when the task clearly requires one.
Cause: Gemma 4 treats tool use as optional by default. Without an explicit instruction to prioritize tool calls, it evaluates whether answering from its training data is sufficient, and often concludes that it is.
Fix: Add tool-priority instructions to the system prompt.
system_instruction = """
When answering user questions, actively use the available tools.
If retrieving information, performing calculations, or taking external actions is required,
you MUST call a tool before generating a response.
Do not attempt to answer from your own knowledge alone.
"""You can also configure this in Antigravity's AGENTS.md file:
## Tool Usage Policy
For all questions requiring external information, call the available tools first.
Generating a text-only response without attempting a tool call is not permitted.The key principle here is to explicitly remove the "just answer in text" fallback from the model's decision space. Once that option is taken off the table, tool invocation rates become much more consistent.
One thing worth knowing: this instruction can have diminishing returns if the tool definitions themselves are poorly described. The model needs to understand what each tool does before it will use it correctly. Write description fields in your tool schema the same way you would explain the function to a new engineer — be specific about what the tool does, what it returns, and when it should be used.
Pattern 2: Malformed JSON on Every Tool Call
Symptom:
Error: Invalid tool_call format: expected JSON object, got malformed output
Sometimes the model decides to call a tool but produces invalid JSON — trailing commas, inline comments, extra whitespace inside a string that breaks parsing. The request fails at the schema validation step before it even reaches your tool implementation.
Cause: Gemma 4 occasionally injects non-standard elements into the JSON it generates for tool calls. This becomes more frequent when temperature is above 0.7 — at higher temperatures, the model is being rewarded for variance, which works against the structural precision that JSON requires.
Fix 1: Lower the temperature
In Antigravity's model config, set temperature to somewhere between 0.1 and 0.3 for any agent task that requires reliable tool invocation. You are optimizing for structural correctness, not creative variation.
Fix 2: Simplify the tool schema
# Avoid this: deeply nested schema — common failure point with Gemma 4
tools = [{
"name": "search_product",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"enum": ["exact", "fuzzy", "regex"] # avoid complex enum conditions
},
"filters": {
"type": "object",
"properties": {
"category": {"type": "string"},
"price_range": {
"type": "array",
"items": {"type": "number"} # avoid 3+ levels of nesting
}
}
}
}
}
}]
# Use this instead: flat, explicit schema — one to two nesting levels maximum
tools = [{
"name": "search_product",
"description": "Search for products by keyword and optional category. Returns a list of matching products with name, price, and availability.",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Search keyword, e.g. 'wireless headphones'"
},
"category": {
"type": "string",
"description": "Product category to filter by, e.g. 'electronics', 'clothing'. Optional."
}
},
"required": ["query"]
}
}]Keeping the schema to one or two nesting levels almost always improves success rates. A practical mental model: design the schema for the strictest, least capable model that might need to parse it. If the schema would confuse a smaller model, Gemma 4 may also stumble on it under certain conditions.
If you have multiple tools with complex parameter sets, consider breaking a single complex tool into two simpler ones. The tradeoff in implementation complexity is usually worth the reliability gain.
Pattern 3: Tools Work Locally but Break Through Antigravity IDE
Symptom: Running Gemma 4 directly via Ollama works fine. The same workflow fails consistently when routed through Antigravity IDE.
Cause: Antigravity's default context length configuration for local models is often set to 4,096–8,192 tokens. When your system prompt, tool definitions, and existing conversation history exceed that limit, the tools array is silently dropped from the request. The model receives the conversation without any tool definitions attached, has no way of knowing tools are available, and responds in plain text.
Diagnosis: Open Antigravity's developer tools (Cmd+Shift+J on macOS), go to the Network tab, and inspect the outgoing chat completions request payload.
{
"model": "gemma4:latest",
"context_length": 4096,
"tools": []
}If tools is an empty array or absent entirely, the context window is the issue.
Fix: Increase context_length in Antigravity's model settings to at least 32768:
{
"models": {
"gemma4:latest": {
"context_length": 32768,
"num_ctx": 32768
}
}
}When using Ollama directly, you can set this in a Modelfile instead:
FROM gemma4
PARAMETER num_ctx 32768
Be aware that increasing the context window raises RAM consumption proportionally. If the higher setting causes memory pressure, you may need to reduce the number of concurrent agent sessions or choose a quantized version of the model. The Gemma 4 OOM fix guide covers that side of the equation.
If None of These Work
1. Update Gemma 4 to the latest version
ollama pull gemma4:latestFunction Calling support in earlier builds of Gemma 4 had documented issues. The latest release resolves several of them. It's worth pulling the latest before spending time on more complex debugging.
2. Fall back to structured output
If tool calling remains unstable after all the above adjustments, structured JSON output mode is a viable alternative. Instead of using the tool call mechanism, you ask the model to return a JSON object in a specific schema via response_format in Antigravity's settings. You then parse and route that output yourself. It requires more implementation work but bypasses the tool calling layer entirely.
3. Consider a hybrid model setup
The primary reasons to run Gemma 4 locally are cost savings and data privacy. For business logic where Function Calling reliability genuinely matters — external API calls, database writes, multi-step automation — a hybrid approach is often the more defensible decision: Gemma 4 for classification and lightweight reasoning, a cloud model like Gemini 2.5 Flash for tool-dependent tasks. This separation tends to reduce both debugging time and production incidents. The Gemma 4 agent building guide covers design patterns for this kind of hybrid setup in more detail.
For broader agent debugging techniques beyond tool calls, the agent debugging guide is a useful next read.
Where to Start
Set temperature to 0.2 and simplify your tool schema first. In my experience, those two changes resolve the majority of Gemma 4 tool-calling failures. If that doesn't do it, open the developer tools and check whether the tools array is actually being sent in the request payload — that single check will tell you whether context length is the remaining culprit.