A visitor asks a museum kiosk, ‘Is the east gallery open on Sunday?’ A language model can write a convincing answer, but it may know yesterday’s hours rather than the current closure notice. Gemini API function calling lets an application provide declarations for tools and receive a model-proposed function call. The application still controls which code executes, what data the tool may read and how results reach the visitor. This guide designs a narrow read-only museum-hours lookup, with explicit handling for stale notices and ambiguous dates. It does not claim a live Gemini experiment.
Make the museum schedule the authority
Start from a trusted schedule system managed by museum staff. Each record should have branch or gallery ID, current opening hours, closure exception, effective dates, time zone, revision timestamp and approval status. Do not let the model infer a current opening from its training knowledge or from search snippets with unknown dates. Decide which official record wins if the regular weekly schedule conflicts with a holiday notice, and make that precedence explicit in application code rather than in a vague prompt.
The kiosk should present a fallback when the schedule source cannot be reached. ‘I cannot confirm today’s hours; contact the front desk’ is preferable to an invented closing time. Avoid treating a public event date as proof of a gallery’s operating hours. Keep a separate accessibility message if a temporary closure affects an elevator or accessible entrance. These details must be human-maintained, not created when a model needs an answer.
Understand a declared function and its limitations
Gemini function calling uses tool declarations describing a callable function name, purpose, parameters and required arguments. The model may suggest a call with structured arguments, and the application can execute the corresponding authorized function and send its output back to the model for an answer. This does not grant the model inherent API privileges. Your server should be the trusted boundary: parse and validate proposed arguments, enforce a fixed tool allowlist, and reject anything outside its read-only purpose.
Google documents function calling modes such as auto, any and none, with newer tooling also describing validated behavior; the exact configuration depends on API surface and model. AUTO allows the model to decide whether to suggest a call or answer, while ANY can constrain output toward a function call. Neither mode is an authorization policy. Even a schema-compliant call might ask for the wrong branch ID or date. Test the actual SDK and model version before deployment.
Define a narrow lookup contract
Design a single function, such as get_gallery_hours(gallery_id, local_date), with a fixed set of allowed gallery IDs and an ISO-style date string. The server resolves the date in the museum’s time zone, looks up only approved public records, and returns the source title, effective interval, updated_at and opening status. It must never accept database SQL, arbitrary URLs, filesystem paths, credentials, visitor identity or raw commands as arguments. Those inputs are unrelated to a visitor’s hours question.
If a user asks to ‘change Sunday hours,’ do not expose a write function in this kiosk workflow. Respond with the appropriate staff contact or request procedure. Make the access controls real on the server, not just present in a prompt saying ‘please do not edit.’ Keep private operations on a separate privileged service. A tool result should distinguish closed, open, special-event-only and unknown states so the model is not pushed to collapse missing data into a confident yes or no.
Execute only allowed calls and preserve source dates
A normal path is: visitor asks, Gemini proposes get_gallery_hours with validated arguments, the server queries a current approved schedule, and the model composes a short answer citing the effective notice. The process illustration shows each trust boundary separately. A model-proposed call can be rejected at any point for unsupported gallery IDs, future dates outside the schedule horizon, permission failure or malformed arguments. A rejection should yield a safe clarification or handoff, not an improvised answer.
Treat the tool response as data, not instructions. A compromised notice field might contain text like ‘ignore previous rules’; never pass it as higher-priority control logic. Sanitize and constrain output fields, and display only necessary public data. Log tool name, validated arguments, source record revision and outcome without storing the visitor’s entire voice recording unless a separate approved purpose requires it. Clear error states help operators diagnose missing official records.
Compare a plausible guess with a sourced answer
Imagine the model’s general knowledge suggests that a gallery usually opens at ten. The official schedule, however, contains a temporary closure for the specific Sunday. The first state in the comparison diagram is an unsupported generic guess. The second shows a read-only tool result with the closure date. The third is a visitor-facing answer that names the closure and points to an approved source or staff contact. It is an illustrative scenario, not a real museum or measured Gemini output.
A tool result alone can also be wrong when the database has not been updated. Check that its effective date covers the visitor’s question and that the record is marked published. A missing approved notice should never become ‘open as usual’ by default. Preserve temporal context when the visitor says ‘tomorrow’ or ‘next Sunday’: resolve dates using the museum’s local time zone before querying the tool. Ask a clarification if the location or date truly cannot be determined.
Use function modes without expanding permissions
Use auto when natural-language clarification may be appropriate; use stricter tool-call behavior only where the application can actually satisfy the requested read action. For example, if a visitor only says ‘hello,’ forcing a schedule lookup is unnecessary. If they ask about an unavailable branch, a rigid call mode should still permit a safe error path after server validation. Do not treat an ANY or VALIDATED setting as confirmation that results have been checked for freshness or permissions.
Implement independent application tests that deliberately supply malformed IDs, an injected instruction in a source title, wrong time zones, canceled events, and a stale publication timestamp. Confirm the server never exposes a write route. Review the model’s final wording for undue certainty: ‘The east gallery is closed Sunday according to the notice updated Friday’ is more auditable than ‘I’m certain it will be closed.’ Accessibility instructions deserve their own controlled source checks.
Audit failures and prevent quiet fallbacks
Define and test distinct states for no tool call, rejected arguments, failed source lookup, outdated record and verified schedule response. These states should not all produce the same helpful-looking sentence. A reliable kiosk can say it does not know when a source cannot be authenticated. Monitor tool latency and failed lookups, but avoid promoting speed over correctness. If a newer notice supersedes the cached record, the application must retrieve the right revision before telling visitors where to go.
Use synthetic examples in the validation set, not personal visitor recordings. Have staff annotate expected outcomes for a typical day, holiday, unexpected closure, two similarly named galleries and a time-zone boundary. Compare the final answer to the approved source record, not to the model’s self-reported confidence. A function call may be technically well formed yet still omit a critical condition, such as a separate entrance being closed.
Launch with a safe staff handoff
Before launch, museum staff confirm the approved hours feed, tool permissions, escalation contact and time-zone assumptions. Keep a visible date on the answer, a way to inspect the source, and a manual path if the system is unavailable. Test screen readers, keyboard input and clear error messages. Version the tool schema and source mapping so maintainers can investigate a wrong answer without guessing what the model was allowed to see.
The main benefit is a constrained path from a question to an approved record. Gemini can help choose a tool and word a response, but the institution controls data access, freshness, publication status and final visitor safety. Avoid adding inventory updates, booking or email tools to this same kiosk execution context merely because the model can produce their arguments. This design is a documented hypothetical workflow, not an assertion of observed API performance.
How We Research
For our November 2026 editorial review, we consulted the named official developer sources: Gemini API function calling guide; Gemini function calling legacy reference. We checked documented feature scope, supported inputs, configuration concepts and limitations against a clearly hypothetical, nonproduction library or museum workflow. We did not run paid API calls, access personal visitor records, independently benchmark model quality, conduct a real deployment, capture vendor interface screenshots or verify a particular institution’s permissions. Each figure is original conceptual instructional artwork, not a live test result. Readers should verify current documentation, regional availability, pricing, plans, security policy and release versions before a trial.
Frequently Asked Questions
A proposed call is not authorization; the application controls tool execution and validates arguments.
No. AUTO allows the model to decide whether to call a tool; the application must enforce its own information policy.
No. Output mode only shapes the model response, while server permissions must prevent unauthorized writes.
Return an explicit unverified state and a staff contact instead of inventing a current answer.
Resolve the date using the museum’s local time zone and clarify the location when needed.