Import from OpenAPI
Turn an OpenAPI 3.x or Swagger 2.0 spec into a set of HTTP tools in one step, instead of describing each endpoint by hand.
If the API you want your agents to call publishes a spec, you do not have to describe its endpoints one at a time. Import OpenAPI on the Tools screen takes an OpenAPI 3.x or Swagger 2.0 document and creates one HTTP tool per operation.
Each path-and-method pair becomes a tool that plugs into the same executor a hand-written HTTP tool uses — there is no separate "imported tool" code path.
What the import maps
| Spec element | Becomes |
|---|---|
| Path parameters | {{param}} placeholders in the tool's URL |
| Query parameters | Arguments in the tool's input schema |
| JSON request body | Arguments in the tool's input schema |
| Operation summary / description | The tool description the model reads |
At call time the executor routes arguments to query parameters for GET and DELETE, and into the JSON body for POST and PUT.
Path placeholders are rewritten to the product's own syntax
OpenAPI writes /pets/{petId} with single braces. An imported tool is written
as /pets/{{petId}} — the same {{ }} used in headers, bodies and prompts —
so there is one syntax to learn. The executor still understands the
single-brace form, so a hand-written tool using it keeps working.
Headers are not arguments
Header parameters in the spec are deliberately not turned into tool arguments. The executor cannot route an argument into a request header, so exposing them would quietly mis-send them as query or body fields.
Supply authentication and any other static headers once, at import time, in the Headers field — an Authorization header entered there applies to every tool the import creates. Use a variable for the value rather than pasting a key:
Authorization: Bearer {{ global.vendor_token }}Groups
An import creates a tool group named after the spec, so forty endpoints arrive as one named set rather than forty loose tools. You can assign the whole group to an agent, or pick from it.
Preview, then save
The import previews first: it parses the spec and shows you every tool it would create, so you pick a subset rather than accepting all of them. Nothing is written until you save. Each operation in the preview shows what it says it does — Reads only, Changes something or Deletes something, with Safe to repeat and Reaches outside — from its method, as an HTTP tool takes them. Importing the same spec again keeps what you set on a tool, as long as its method is the same; a changed method takes its new method's answers.
Take that step seriously — a generated description is only as good as the spec's:
- Delete the operations nobody needs. Every tool an agent holds costs prompt tokens on every turn.
- Rewrite vague descriptions. The description is how the model decides whether to call it.
- Consider tool policy: imported tools reach a system outside the workspace, and a spec that declares nothing about safety lands as
undeclared.