Tool calling

The gateway supports tool (function) calling on Chat Completions, the Responses API, and Messages. Declare your tools in the request; if the model decides to use one, the gateway streams the tool call back to you.

Relay mode

Your function tools run in relay mode: the gateway does not execute your functions. It declares your tool definitions to the model, returns the call the model wants to make, and stops. You run the tool and send the result back on the next turn. A typical loop:

Send a request with tools (and optionally tool_choice).
The model responds with one or more tool calls and a tool-call finish reason instead of final text.
Run each tool yourself and append the result to the conversation.
Send the updated conversation back; the model continues (more tool calls, or a final text answer).

Use a model that supports tools. Validate the returned function name and arguments before execution, and keep a limit on tool-loop iterations. Each follow-up model request is billed separately.

Chat Completions

Request — tools[] are function definitions; tool_choice is auto (default), none, required, or { "type": "function", "function": { "name": "..." } }.

curl https://api.impossibl.com/v1/chat/completions \
  -H "Authorization: Bearer $IMPOSSIBL_API_KEY" \
  -H 'content-type: application/json' \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role":"user","content":"What is the weather in Paris?"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Get the current weather for a city",
        "parameters": {
          "type": "object",
          "properties": { "city": { "type": "string" } },
          "required": ["city"]
        }
      }
    }]
  }'

Response — the assistant message carries tool_calls and finish_reason is tool_calls. Each call’s function.arguments is a JSON-encoded string.

{
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "content": null,
      "tool_calls": [{
        "id": "call_abc",
        "type": "function",
        "function": { "name": "get_weather", "arguments": "{\"city\":\"Paris\"}" }
      }]
    },
    "finish_reason": "tool_calls"
  }]
}

Returning the result — append the assistant message and a tool message whose tool_call_id matches, then send the conversation again:

{ "role": "tool", "tool_call_id": "call_abc", "content": "{\"tempC\":18}" }

Streaming — tool calls arrive as delta.tool_calls[] fragments. The first fragment for a call carries id, type, and function.name; later fragments stream function.arguments text. The index field correlates fragments of the same call.

Responses API

Show request format

Request — Responses flattens the function fields onto each tool. tool_choice is auto / none / required / { "type": "function", "name": "..." }.

curl https://api.impossibl.com/v1/responses \
  -H "Authorization: Bearer $IMPOSSIBL_API_KEY" \
  -H 'content-type: application/json' \
  -d '{
    "model": "openai/gpt-4o-mini",
    "input": "What is the weather in Paris?",
    "tools": [{
      "type": "function",
      "name": "get_weather",
      "description": "Get the current weather for a city",
      "parameters": {
        "type": "object",
        "properties": { "city": { "type": "string" } },
        "required": ["city"]
      }
    }]
  }'

Response — the model emits a function_call output item with a call_id and a JSON-string arguments:

{ "type": "function_call", "id": "fc_1", "call_id": "call_abc",
  "name": "get_weather", "arguments": "{\"city\":\"Paris\"}", "status": "completed" }

Returning the result — resend the prior input and output items, then add a function_call_output referencing the same call_id. Responses is stateless; sending only the result loses the conversation:

{ "type": "function_call_output", "call_id": "call_abc", "output": "{\"tempC\":18}" }

Streaming — a response.output_item.added event opens the function_call item, response.function_call_arguments.delta events stream the argument text, and response.function_call_arguments.done closes it.

Messages (Anthropic)

Show request format

Request — tools[] use input_schema; tool_choice is { "type": "auto" }, { "type": "any" }, { "type": "tool", "name": "..." }, or { "type": "none" }. (A bare claude-... model id routes to Anthropic; any provider/model id also works here — see SDKs & integrations.)

curl https://api.impossibl.com/v1/messages \
  -H "x-api-key: $IMPOSSIBL_API_KEY" \
  -H 'content-type: application/json' \
  -d '{
    "model": "claude-haiku-4-5",
    "max_tokens": 256,
    "messages": [{"role":"user","content":"What is the weather in Paris?"}],
    "tools": [{
      "name": "get_weather",
      "description": "Get the current weather for a city",
      "input_schema": {
        "type": "object",
        "properties": { "city": { "type": "string" } },
        "required": ["city"]
      }
    }]
  }'

Response — a tool_use content block (with a parsed input object) and stop_reason: "tool_use":

{ "type": "tool_use", "id": "toolu_1", "name": "get_weather",
  "input": { "city": "Paris" } }

Returning the result — send a user turn containing a tool_result block referencing the tool_use_id:

{ "role": "user", "content": [
  { "type": "tool_result", "tool_use_id": "toolu_1", "content": "{\"tempC\":18}" }
]}

Streaming — the tool_use block opens with a content_block_start, its input streams as content_block_delta events of type input_json_delta (partial_json), and closes with content_block_stop.

Across all three surfaces, arguments arrive as JSON text (a string for OpenAI-style calls, streamed partial_json for Anthropic). Parse them yourself before running the tool, and tolerate empty/partial fragments while streaming.

Images in tool results

A tool that returns an image can hand it straight to the model — the image reaches the model instead of being flattened to text. Each surface uses its own content part inside the tool result:

// Chat Completions — an image_url part on the `tool` message
{ "role": "tool", "tool_call_id": "call_abc", "content": [
  { "type": "text", "text": "screenshot of the checkout page" },
  { "type": "image_url", "image_url": { "url": "data:image/png;base64,iVBORw0KGgo..." } }
]}

// Responses — an input_image part in the function_call_output
{ "type": "function_call_output", "call_id": "call_abc", "output": [
  { "type": "input_text", "text": "screenshot of the checkout page" },
  { "type": "input_image", "image_url": "data:image/png;base64,iVBORw0KGgo..." }
]}

// Messages — an image block inside tool_result
{ "role": "user", "content": [
  { "type": "tool_result", "tool_use_id": "toolu_1", "content": [
    { "type": "text", "text": "screenshot of the checkout page" },
    { "type": "image", "source": { "type": "base64", "media_type": "image/png", "data": "iVBORw0KGgo..." } }
  ]}
]}

Tool-result images must be data: base64 URIs. Unlike a user message, an http(s) URL in a tool result returns 400 — the gateway does not fetch remote images on your behalf. Fetch it yourself and inline the bytes. User-message images still accept both sources (see Vision).

Anthropic, Gemini, and the OpenAI Responses API receive the image natively inside the tool result. Chat-Completions backends receive it as a single user message placed immediately after the whole tool-result group, so parallel tool calls stay intact. Sending an image to a model whose input_modalities explicitly exclude image returns 400 invalid_request_error rather than silently dropping it. A model that declares no modalities at all is unverified, not text-only, and still accepts images.

Gemini thought signatures

Gemini 3 models attach an opaque signature to the first function call of each step and reject the tool-result turn unless it comes back verbatim. The gateway round-trips it for you: on Chat Completions the tool call carries extra_content.google.thought_signature (Google’s OpenAI-compat mapping — in streaming it rides a tool_calls fragment), and on the Responses API the function_call item carries the same extra_content field. Send the tool call back exactly as you received it — clients that echo the assistant message unchanged preserve this context. Check that your framework does not strip unknown fields. The Gemini-native endpoint uses Google’s own Part.thoughtSignature unchanged. Tool calls from another model. Gemini 3 also rejects any tool call in the history that carries no signature at all — the case when you switch an ongoing session to Gemini, synthesise a call yourself, or use a client that strips unknown fields. The gateway marks those calls with Google’s documented skip-validation sentinel so the turn is accepted; a real signature you send is always preserved byte-for-byte and never replaced.

Mistral on Azure Foundry

Mistral’s serving stack on Foundry requires tool-call ids to be exactly nine alphanumeric characters, and requires every tool to carry a description. An OpenAI-style call_abc123 or an Anthropic-style toolu_01ABC from an earlier model would be refused. The gateway rewrites ids consistently across the request (each id and the tool_call_id referring to it get the same value) and supplies an empty description when you omit one, so a tool history built against any other provider replays unchanged. Ids in the response are the ones the provider minted; your own ids are never rewritten on the way back.

Provider-executed search

Search the web or X with an xAI model

On Responses, supported xAI models can run web_search and x_search on the provider’s server. Unlike your function tools, these searches do not need an application round trip.

{
  "model": "xai/grok-4.20-0309-reasoning",
  "input": "Find recent public announcements about the James Webb Space Telescope and cite sources.",
  "tools": [{"type": "web_search"}]
}

Send this body to POST /v1/responses. Search invocations add a $0.005 charge each on top of token usage for gateway-paid requests. usage.server_side_tool_calls reports invocations when present; one request can use more than one search.These native searches execute only on xAI routes. On other providers they are filtered out; tool_choice: "required" returns 400 if no executable tools remain. Do not assume that an answer used search just because your request included a search tool. Code execution is not supported.

Get started

Build

Modalities

Manage

Relay mode

Chat Completions

Responses API

Messages (Anthropic)

Images in tool results

Gemini thought signatures

Mistral on Azure Foundry

Provider-executed search

​Relay mode

​Chat Completions

​Responses API

​Messages (Anthropic)

​Images in tool results

​Gemini thought signatures

​Mistral on Azure Foundry

​Provider-executed search

Relay mode

Chat Completions

Responses API

Messages (Anthropic)

Images in tool results

Gemini thought signatures

Mistral on Azure Foundry

Provider-executed search