Workflow:Googleapis Python genai Function Calling and Tools
| Knowledge Sources | |
|---|---|
| Domains | LLMs, Function_Calling, Tool_Use, Agentic_AI |
| Last Updated | 2026-02-15 14:00 GMT |
Overview
End-to-end process for integrating external tools and functions with Gemini models using the Google GenAI SDK, supporting automatic function calling, manual tool orchestration, and MCP server integration.
Description
This workflow enables Gemini models to interact with external systems by calling functions defined by the developer. The SDK supports three modes: automatic function calling (AFC) where the SDK handles the entire call-respond loop, manual function calling where the developer controls each step, and Model Context Protocol (MCP) integration for connecting to external tool servers. Tools are defined as Python functions, FunctionDeclaration objects, or MCP sessions, and the model decides when and how to invoke them based on the user's query.
Usage
Execute this workflow when your application needs the Gemini model to access real-time data, perform calculations, interact with databases, call external APIs, or execute any action beyond its training data. This is essential for building AI agents, assistants with tool access, or any application requiring the model to take actions in the real world.
Execution Steps
Step 1: Client Initialization
Create a GenAI client with either Gemini Developer API or Vertex AI credentials. For MCP integration, the async client (client.aio) is required since MCP sessions are inherently asynchronous.
Key considerations:
- MCP support requires the async client
- Function calling works with both Gemini Developer API and Vertex AI
Step 2: Tool Definition
Define the tools the model can use. There are three approaches: pass Python functions directly (the SDK auto-generates the function declaration from the function signature and docstring), create explicit FunctionDeclaration objects with JSON schema parameters, or provide MCP ClientSession objects. Multiple tools of different types can be combined in a single request.
Key considerations:
- Python functions must have type annotations and docstrings for automatic schema generation
- FunctionDeclaration gives full control over the parameter schema
- MCP sessions expose all tools from the connected MCP server
- The tools parameter in GenerateContentConfig accepts a mixed list of all tool types
Step 3: Tool Configuration
Configure how the model should use the defined tools. Set the function_calling_config mode to AUTO (model decides), ANY (model must call a function), or NONE (no function calling). Configure automatic_function_calling to enable/disable the AFC loop, and set maximum_remote_calls to limit the number of automatic call iterations.
Key considerations:
- In AUTO mode, the model decides whether to call a function or respond directly
- In ANY mode, the model always returns a function call, which can lead to infinite loops without AFC limits
- The default maximum_remote_calls for AFC is 10
- Disabling AFC returns raw function call parts for manual handling
Step 4: Content Generation with Tools
Invoke generate_content with the tool-equipped configuration. If AFC is enabled, the SDK automatically executes the function, sends the result back to the model, and repeats until the model produces a final text response. If AFC is disabled, the response contains function_call parts that the developer must handle.
Key considerations:
- AFC handles the entire multi-turn tool use loop automatically
- Without AFC, check response.function_calls for pending function invocations
- Streaming with AFC is supported via generate_content_stream
- MCP tool calls are executed by the MCP session automatically during AFC
Step 5: Manual Function Execution (if AFC disabled)
When AFC is disabled, extract function call parts from the response, execute the corresponding functions locally, and send the results back to the model in a follow-up generate_content call. Construct a function response part using Part.from_function_response() and include it with the conversation history.
Key considerations:
- Preserve the full conversation history: user content, model function call content, tool response content
- Function responses use role tool in the Content object
- Error responses can be sent back to let the model handle failures gracefully
- Multiple function calls may be returned in a single response (parallel function calling)
Step 6: Response Processing
Process the final text response after all tool interactions are complete. The response follows the same structure as standard text generation, with the complete conversation history available for inspection.
Key considerations:
- The AFC loop history is accessible for debugging and logging
- Token usage includes all intermediate tool-calling turns
- For streaming with AFC, chunks may include intermediate tool-call results