FunctionGemma: formatting and best practices

Google's live documentation for FunctionGemma, a variant of Gemma 3 270M trained for function calling. It is a spec for how a tool call looks on the wire to a very small model, and it says plainly what the model was not trained to do. Read 2026-10-04. The page carries no date, so there is no published: field.

The wire format

Turns. Standard Gemma wrappers (<start_of_turn>role ... <end_of_turn>) with three roles: user, model, and developer. The developer turn comes first and carries the tool definitions.
Trigger phrase. The developer turn must contain "You are a model that can do function calling with the following functions". The page says this phrase switches the model from general chat to tool use.
Six control tokens in three pairs. <start_function_declaration> / <end_function_declaration> define a tool. <start_function_call> / <end_function_call> mark the model's request. <start_function_response> / <end_function_response> return the result.
One escape token. <escape> wraps every string value in declarations, calls and responses, so braces, commas and quotes inside a string are not read as structure. Numbers are not escaped. Types are uppercase (STRING, OBJECT); enums are written as a list of escaped strings.
Call and response shape. call:get_current_weather{location:<escape>Tokyo, Japan<escape>} from the model; response:get_current_weather{temperature:15,weather:<escape>sunny<escape>} back from the application. The application intercepts the call rather than showing it to the user, runs the function, and sends the response in.
Stop sequence. <start_function_response> should also be set as an extra stop sequence in the inference engine, so generation halts and hands control to the application. The page gives no other decoding or sampling advice.

What is supported

Single turn: one query, one call.
Parallel: several independent requests in one query give several calls in one response (the page's example pairs a weather lookup with a stock price).

What is not trained

Multi-step chaining, where one tool's output feeds the next call (roll a d20, then test whether the result is prime).
Multi-turn parameter collection ("book me a table" ... "for how many?" ... "four"), which needs state held outside the model.
Semantic nuance. Indirect wording can miss the right tool; "cold" or "hot" may not trigger a temperature tool.

Google says it expects some generalization to these cases, especially after fine-tuning. It gives no measurements for any of the claims here.

Mitigations the page recommends

Enrich tool descriptions with the words users will actually use (its example appends "can be used to determine if the weather is hot or cold in a given location"). The page calls this often the most effective fix.
Make user queries more explicit, which depends on the user.
Fine-tune on data that maps indirect phrasings ("is it nice out?") to the right tool.

Cross-spoke context

Runner-up spoke: llm-providers-wiki, where FunctionGemma appears as one row in gemma-variants ("base for specialized function-calling models"). The model-family facet lives there; this page holds only the calling protocol. Not duplicated.

Where it sits here

The loop lives in the application, not the model: the model emits a delimited call, the harness executes it, the harness feeds the result back. For a 270M model, that division is explicit enough to document token by token. It sits alongside model-context-protocol, which standardizes the tool-definition side for large models, and how-many-tools-should-an-agent-see, which measures how tool-list size affects selection. See synthesis ("A 270M model gets a tool protocol, and the chaining is left to the harness").