tools / tool_choice interface on /v1/chat/completions, so existing OpenAI tool-calling code works unchanged.
The cycle
- You send a request with a
toolsarray describing the functions available. - The model replies with
finish_reason: "tool_calls"and one or moretool_calls. - You execute the function yourself and append the result as a
role: "tool"message. - You send the conversation back; the model produces its final answer.
1. Declare the tools
2. The model asks for a call
arguments is a JSON-encoded string, not an object — parse it before use.
3. Return the result
Append the assistant message and atool message carrying the matching tool_call_id:
tools on the follow-up. Every tool_call_id must be answered by exactly one tool message.
Controlling when tools are used
Tool calling disables the response cache
Gemini thinking models
Gemini’s thinking models attach a thought signature to each tool call, and Vertex rejects a follow-up whose tool history is missing it. The OpenAI wire format has no slot for this, so MeshAPI exposes it in two places:- on the tool call itself, as
tool_calls[].thought_signature - in a side channel,
message.reasoning_details, for clients that strip unknown fields fromtool_calls
Some frameworks — LangChain among them — strip both fields automatically. MeshAPI detects the resulting rejection and retries once with the unsigned tool exchanges demoted to plain text, so your request still succeeds. You lose the thinking context on that turn, but you do not get an error. If you can preserve the signature, do; if your framework won’t, the fallback covers you.
Related
- Caching — why tools bypass the response cache
- Structured Output — for shaping a response rather than calling code
- The SDKs tab has per-language tool-calling examples for Python, Node.js, and Go