Wrap a REST API with web_get
This is the no-code path for the tools surface described in Integrations: exposing a single third-party REST endpoint to an agent without deploying anything.
web_get is the built-in HTTP fetcher. Out of the box the agent chooses the URL, method, headers, and body, and gets back the raw response plus envelope fields the model doesn't need. Usable for ad-hoc browsing, weak as a tool. Four configuration fields turn it into a purpose-built client for one API: rename it after the verb it implements, rewrite its description, pin every argument the LLM shouldn't pick, and project the response to the fields the model should reason over.
The four ingredients
All four fields live on the agent's tool_configurations entry.
The map key is the name the agent sees. Don't call it fetch_url; call it get_github_issue or lookup_jira_ticket. The agent decides whether to call a tool from this name, so it should read like the verb it implements.
The description field overrides the default tool description shown to the agent. Write one or two sentences that describe what the tool does, what input it expects, and when to reach for it. Describe the API you're wrapping, not the mechanics of web_get.
The argument_override field hardcodes any of the underlying WebGetToolParameters you don't want the LLM to decide: method, the static parts of headers, the request body, timeout_seconds, head_lines, tail_lines, max_content_bytes, even the url itself for a zero-input tool. Anything in this map is invisible to the agent; anything you leave out remains its responsibility.
The output_transform field is a jq expression applied to the response before it reaches the model. The raw WebGetResponse carries response_headers, total_lines, truncated, and the redirected url alongside the body. For most wrapped APIs the only thing worth showing the agent is the parsed body. Project aggressively.
Example: a document fetcher
A natural pairing for corpora_search: the built-in search tool returns snippets, but an agent often needs the full document body to reason over. Vectara's GET /v2/corpora/{corpus_key}/documents/{document_id} endpoint returns the whole document, and there is no built-in tool that wraps it. This configuration is that wrapper.
The agent chooses only the url, built from a corpus key and a document id it has seen in a search hit. The method, API key, accept header, timeout, and truncation are pinned. The response is projected to the id, the metadata, and the document text joined from parts[].
A VECTARA DOCUMENT FETCHER BUILT ON WEB_GET
Code example with json syntax.1
Rules of thumb
Hardcode every field the LLM doesn't need to choose. Each free parameter is one more chance the agent picks something nonsensical, and every fixed parameter is one fewer thing the description has to explain.
Truncate before you transform. head_lines, tail_lines, and max_content_bytes run on the server before bytes ship back; output_transform runs on whatever made it through. Doing both keeps a runaway page from blowing up the context window even if the transform happens to keep the whole body.
Don't paste secrets into argument_override. Reference an agent-scoped secret instead, so credentials aren't stored alongside the agent definition and can rotate without touching the configuration.
If the integration needs logic the description can't express (chained calls, response pagination, OAuth refresh), stop and reach for a lambda tool or MCP. web_get is the right tool when one request maps to one tool call.
For the bigger picture of how tools sit alongside data sources and connectors, see Integrations. For more on output_transform and pairing the fetcher with web_search, see Transforming tool output.