Gemini API and Function Calling
Explore how the Gemini API processes model-generated function-call requests, including validation, authorization checks, and execution within the application. Learn to separate model tool requests from actual operations and manage authorization, error handling, and conversation history for reliable system behavior.
The user asks, "What is the status of repair R-204?" Gemini returns a function-call request named get_repair_status with arguments {"repair_id": "R-204"}. The application has not executed the repair lookup yet.
The tool declaration exposes get_repair_status to Gemini, but the application maps that name to the lookup function in repair_status.py. The application must validate the function-call arguments, enforce the required authorization checks, and dispatch the request to the appropriate implementation.
Separating model-generated tool requests from application-controlled execution makes authorization, error handling, and execution limits explicit and testable.
Who runs R-204?
Before looking at the dispatcher, identify what has actually happened and which operation should happen next:
A function call is a model-generated request for an application operation. The application inspects the name and arguments, executes its implementation if permitted, and supplies the result to the model.
Passing validation still does not prove successful execution: The lookup can fail after dispatch. Track permitted attempts separately from successful returns so that an error cannot masquerade as a completed repair lookup.
This tempting implementation hides three separate defects:
while True:response = ask_model(history)call = response.function_calls[0]result = lookup(call.args["repair_id"])
Line 1: Allows unlimited repetitions.
Lines 2–3: Assume every response contains a call and ignore additional calls in the same response.
Line 4: Executes generated arguments without checking function name, argument shape, or the caller’s permitted repair identifiers.
An out-of-scope request for R-999 reaches the lookup. Repeated requests never terminate. If subsequent history is reconstructed from visible call fields, required response metadata can also disappear. Each defect needs a repair at its own boundary; a stronger prompt or a Pro-tier model supplies none of these controls.
Place each request field
For the repair-status request, distinguish these five components of the model and tool interaction:
System instruction: Defines how the model should respond: "Use retrieved repair records and do not invent an estimated completion time."
User content: Contains the user's question, "What is the status of repair R-204?", as a text part.
Function declaration: Defines the tool interface exposed to Gemini, including the name
get_repair_status, its description, and the required string parameterrepair_id.Model response: Contains candidate content made up of parts, such as text or function-call requests. Additional response metadata may be available separately.
Function response: Contains the result returned by application code after executing the requested tool operation.
The Google Gen AI Python SDK provides FunctionDeclaration and Tool for defining tools, and GenerateContentConfig for configuring requests made through client.models.generate_content.
For this example, trusted application state contains the authorized repair identifiers: allowed_ids = {"R-204"}. In production, the application must derive this allowlist from verified user identity and authorization data. Adding entitled: true to model-generated arguments does not grant the user permission to access a repair record.
Inspect candidate parts rather than treating every response as plain text. A response can ask for an action ...