Skip to main content
Point an agent at a REST API’s spec and every operation becomes a tool it can call — no per-endpoint wrapper functions, no external MCP process.

Quick Start

1

Load a spec and start the agent

Every operation in the spec becomes a tool the agent can call directly.
2

Install httpx

httpx is needed at call time.
YAML specs also need PyYAML (already a dependency).
Specs or APIs on localhost, private networks (10.0.0.0/8, 192.168.0.0/16, …) or cloud metadata (169.254.169.254) are refused by default. Set ALLOW_LOCAL_CRAWL=true to call a local API during development. See SSRF guard.

How It Works

get_tools() returns one callable OpenAPIOperation per spec operation. When the agent calls one, it builds the request, attaches auth headers, sends it with httpx, and returns the parsed JSON.

Loading a Spec

Provide the spec exactly one of three ways — otherwise a ValueError is raised.

Configuration Options

All constructor arguments are keyword-only. Exactly one of spec_dict, spec_str, spec_url is required.

Methods

OpenAPIOperation

Each tool returned by get_tools() is an OpenAPIOperation. Attributes: name, description, method, path, base_url, parameters, body_schema, body_param, input_schema, auth, header_provider, timeout.

Auth Shapes

The auth dict is keyed by type.

Safety Behaviour

The toolset refuses unsafe requests and never fetches arbitrary URLs while parsing. Framework-injected kwargs are stripped on all paths — free-form, declared, and composed — so durable-execution metadata never leaks into a strict API.

Body Shapes

Every requestBody schema falls into one of three modes, decided in this order. Framework-injected kwargs are dropped in every mode.

Common Patterns

Restrict the tool surface to read-only operations:
Namespace a spec when combining several on one agent:
Rotate auth per request:
Preview a request without calling the API:
Call an operation whose body uses allOf — no special configuration:
Both name and age are advertised to the model and forwarded to the API — a composed spec works with no extra wiring. Force a base URL when the spec has a relative servers: entry:

OpenAPI Toolset vs MCP

Both expose external tools to an agent; reach for the toolset when the API already has a spec. A workaround existed (MCP("npx -y @ivotoby/openapi-mcp-server ...")); the toolset removes the extra process and the npx dependency, and adds first-class tool_filter and tool_name_prefix.

Best Practices

The toolset refuses to attach credentials to an http:// endpoint. If the spec declares a cleartext server, pass an https:// base_url explicitly. A same-host scheme downgrade — a spec supplying http:// for an origin you configured as https:// — is refused too, so a token never travels in the clear.
A large spec can generate dozens of tools. Use tool_filter to keep only read-only or task-relevant operations so the model isn’t overwhelmed.
Two specs may both define get_users. Set a distinct tool_name_prefix per toolset so names stay unique on one agent.
When you point the toolset at a spec URL you do not control, the spec — not just the model — can try to relocate a call. The toolset pins every credentialed request to your configured origin’s host and scheme, so an absolute path in the spec cannot silently send your token somewhere else. Nothing to do — this is on by default; the tool returns a refusal message the model can see.
OpenAPI tools pointed at loopback or private hosts are refused by default because an operation URL that resolves to 169.254.169.254 can read cloud metadata. Set ALLOW_LOCAL_CRAWL=true in your shell only when you explicitly want the agent to call a local API.
build_request(**args) binds arguments to URL, headers and body without any HTTP call — assert the assembled request in a unit test.

MCP

Front external tools as an MCP server

Tools

Build and register agent tools

Toolsets

Group related tools together

Tool Config

Configure how tools run

ALLOW_LOCAL_CRAWL

Opt in to local and private hosts for development