Gemini API Function Calling: Tool Use in Architectural Workflows

What you’ll learn in this guide

Gemini API function calling lets a model do more than generate a text response: it can select a function to use in an external system and prepare the required parameters. The model does not run the function itself; the application connects the model to the external system. Google’s guide describes this approach as a way to perform actions in external systems, retrieve information from sources such as APIs or databases, and extend capabilities with tools such as calculators.

For architecture, interior design, and visualization teams, this structure can serve as the basis for an application that, for example, searches an external material catalog or retrieves project information. The example below shows how the model can prepare the parameters to pass to a catalog search function. Connecting to an actual catalog and using the results depends on how the application is built.

Requirements

To get started, you need a Gemini API key and an environment that can send API requests. The official getting started guide covers the Python SDK, JavaScript SDK, and REST; it also provides examples for Java and Go. This guide uses Python.

Google AI Studio automatically creates a project and API key for new users. You can get the key from the API keys page in AI Studio. The guide shows how to set the key as an environment variable. An API key associates requests with an account and lets you track usage through that account; it also helps apply security restrictions to requests.

Moving to paid usage raises the account’s request limits, and requires Cloud Billing to be configured. Google’s guide specifies a minimum prepaid amount of $5 or the equivalent in your currency for paid credits. This is not an estimate of usage costs; it is the prepaid requirement stated in the source. Check your account and billing settings before switching to paid usage.

The command in the official guide for installing the Python SDK is:

pip install -U google-genai

Building a function call step by step

1. Define the function’s purpose. The function name and description should clearly state what the application does. In this example, the goal is to search an external catalog for suitable materials for a project. The catalog query itself is not run here; the example shows how the model generates the arguments needed for that query.

2. Define what information to request from the model. A user request might look like this:

Projem için açık renkli, taş görünümlü zemin kaplamalarını malzeme kataloğunda ara.

This text illustrates how the model can turn a natural-language request into function parameters. The fields required by the application should be determined by the catalog’s structure; in the example below, the search query is stored in a single text field.

1. Prepare the function schema. Google’s function calling examples define a function name, description, and parameter schema. Parameter types are specified, and required fields are added to the required list. search_materials and the query field below are examples adapted for an architectural catalog.

from google import genai

search_materials_function = {
    "type": "function",
    "name": "search_materials",
    "description": "Searches a project material catalog using a text query.",
    "parameters": {
        "type": "object",
        "properties": {
            "query": {
                "type": "string",
                "description": "The material search query."
            }
        },
        "required": ["query"]
    }
}

Write the description to explain what the function actually does. Choose parameter names that match the fields expected by the connected application. If a catalog requires multiple filters, the schema should be designed accordingly—but fields and filters should be based on information that the system actually has.

1. Send the request to the Gemini API and inspect the function call step. The getting started guide’s examples use the genai.Client() client, an interactions.create request, and result fields such as interaction.output_text. The function calling documentation shows how to check for a function_call type among the response steps and read the function name and arguments.

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Projem için açık renkli, taş görünümlü zemin kaplamalarını ara.",
    tools=[search_materials_function],
)

for step in interaction.steps:
    if step.type == "function_call":
        print("İşlev:", step.name)
        print("Argümanlar:", step.arguments)

In this example, the expected output from the model is the function call’s name and arguments. Review the generated arguments in your application. Connecting to the catalog, running the query, and presenting the results to the user are application steps beyond the scope of this example.

1. Test inputs before using the function in production. Try different project requests and observe which function the model selects and what arguments it generates. For ambiguous requests, design the checks your own system needs to operate safely and correctly. The source guides explain API usage and function call steps; they do not guarantee the accuracy or data quality of any particular architectural catalog.

Common mistakes

• Leaving the function description vague: Clearly state what the tool is expected to do. The function name, description, and parameter definitions should support one another.

• Not matching parameters to the application: Schema fields must match the information expected by the external system. Otherwise, the application may not be able to use the model’s arguments correctly.

• Assuming the model call runs the operation: Function calling generates a call and arguments for interacting with an external system. Running the function in the actual system depends on the application’s connection.

• Handling the API key carelessly: The key helps associate API requests with an account and track usage. The getting started guide shows how to store it in an environment variable.

• Ignoring costs and usage limits: Request limits and billing settings change when you move to the paid tier. Check usage and billing information in AI Studio before getting started.

Implications for architecture and visualization workflows

This approach can be useful for teams that want to route natural-language requests to tools defined by their application. For example, in an interior design project, the model could turn a material search request into a structured catalog query. Retrieving information from an external API or database is another use case mentioned in the source. This does not mean there is a ready-made connection to Revit, 3ds Max, or another design application; the integration has to be built.

For firms and students, key considerations include the API key, compatibility between the application and the external system, request limits, and potential paid usage requirements. The sources do not specify any special hardware requirements. So rather than making assumptions about hardware, it’s better to assess API usage and which data the workflow would send externally.

Next steps

Start by defining a schema for a clearly scoped function, such as catalog search, and checking the returned arguments against sample user requests. Then identify the external API or data source that the application will use to handle those arguments. If you prefer another language, you can also review the JavaScript or REST examples in the official getting started guide. For multi-step conversations, the guide describes previous_interaction_id, where the server manages conversation history, as the recommended approach to state management.

Sources and license

This guide is adapted from Google’s Gemini API function calling and getting started guides. Both sources are licensed under CC BY 4.0. The content has been translated into Turkish and adapted for an architectural material catalog scenario.