Hosted tools

• Listing is not execution. Declaring web_search advertises it. With the default tool_choice: auto, the model chooses whether to call it — the platform never searches before a model call.
• The model authors the arguments. Even a forced tool_choice only constrains the model’s next call; the query or URL is always model-authored, never a copy of your raw message.
• One loop, one terminal. Tool activity is an item on the way to the assistant answer. The same stream continues after each tool round and ends exactly once.
• Zero results is a valid outcome. An empty search is reported as an empty search, not an error and not a reason to silently try another engine.
• Failures stay typed. A tool that cannot run under your policy fails before it is dispatched, instead of quietly running with fewer constraints.

{
  "model": "openai/gpt-5.5",
  "input": "Read https://example.com/pricing and list the plans.",
  "tools": [
    { "type": "web_fetch", "engine": "firecrawl" }
  ]
}

• web_fetch accepts only type and engine. Source filters are inherited from the web_search declaration in the same request.
• Pages are bounded (1 MiB per returned page) and extracted as clean markdown before they reach the model.
• The observation is a web_search_call whose action is {"type":"open_page","url":…}. There is no invented web_fetch_call item.
• A fetch engine that cannot satisfy a requested constraint (for example cache-only retrieval) is not used for that call.

// Platform executes the discovery (default):
{ "type": "tool_search" }

// Your client executes it and returns the picked tools:
{ "type": "tool_search", "execution": "client" }

• Platform execution produces a tool_search_call and a separate tool_search_output carrying the loaded definitions, then continues with those tools available. Client execution emits only the call; you return the output with the same call_id.
• Marking a customer function with defer_loading: true does not by itself turn on platform discovery — list tool_search as well if you want it.
• A function literally named tool_search is your function, not the hosted operation. A request cannot list both.

{
  "model": "openai/gpt-5.5",
  "input": "When is the next release train if releases ship every other Tuesday?",
  "tools": [
    { "type": "datetime", "timezone": "Asia/Hong_Kong" }
  ]
}

• The timezone is an optional IANA name such as Asia/Hong_Kong; it defaults to UTC.
• Execution happens inside the platform with no external API call, so it adds no tool round trip to a provider.

event: response.web_search_call.in_progress
event: response.web_search_call.searching
event: response.web_search_call.completed
data: {"type":"response.web_search_call.completed","item":{
          "type":"web_search_call","status":"completed",
          "action":{"type":"search","query":"…"},"results":[…]}}

# then the assistant continuation, still the same request:
event: response.output_text.delta
event: response.completed

• Non-streaming responses carry the same items inside output, in order.
• A completed search may add URL citations to the assistant text; the sources it used can be requested with the include field.
• Tool results are evidence for the model — they are never rewritten into instructions, and they never end the turn on their own.

curl -N https://api.models.sylphx.ai/v1/responses \
  -H "Authorization: Bearer $SYLPHX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5.5",
    "input": "What changed in the latest release? Cite the pages you used.",
    "tools": [
      {
        "type": "web_search",
        "engine": "auto",
        "filters": { "allowed_domains": ["example.com"] },
        "search_context_size": "medium"
      },
      { "type": "web_fetch", "engine": "exa" }
    ],
    "stream": true
  }'

Tool failures surface on the same typed error envelope as everything else — see errors and retries.