NewsroomTools
中文

Tool

OpenAPI to AI tool schema converter

Paste an OpenAPI or Swagger spec (JSON/YAML) and get ready-to-paste tool definitions for OpenAI, Anthropic, MCP and Gemini — $refs resolved, parameters flattened.

Input

Processing: the spec is posted to this site’s own conversion endpoint and discarded — never stored or sent to third parties. Do not paste specs containing keys or credentials.

Methods
Options

Convert to get a spec summary, per-operation warnings and tool definitions for each provider. The spec is sent to this site’s own endpoint and discarded — nothing is stored.

    How the conversion works

    Each operation (method × path) becomes one tool, named after its operationId — normalized to the a-zA-Z0-9_- alphabet every provider accepts, deduplicated and capped at 64 characters. Operations without an operationId get a generated name like get_users_id. The description keeps your summary plus the raw METHOD path line so the model sees the real endpoint.

    Internal $ref pointers are resolved and inlined because models cannot follow references; recursion cycles and external URLs become placeholders with a warning. Path and query parameters keep their names, header parameters are marked in their description, and requestBody properties are merged into the same input object — following the approach of open-source converters such as fastapi_mcp, while avoiding its known pitfalls: non-object bodies are wrapped in a body field instead of dropped, and colliding names get a __body suffix instead of overwriting each other.

    OpenAPI 3.0 nullable becomes a real JSON Schema null union, readOnly fields are removed from inputs, and allOf groups are merged — the same rules as openapi-schema-to-json-schema. For Gemini, the schema is projected onto its documented subset (nullable flag, anyOf, no oneOf); for OpenAI strict mode, all properties become required with nullable unions and additionalProperties: false.

    FAQ

    Which OpenAPI versions and file formats are accepted?

    JSON or YAML, OpenAPI 3.0/3.1 and Swagger 2.0. Internal $refs (components/schemas, definitions) are resolved and inlined; external file or URL references cannot be fetched and are replaced with a placeholder plus a warning.

    Why do the same tools look different per provider?

    Each API wraps the same parameters differently: OpenAI nests them under function.parameters (or a flat type:function object on the Responses API), Anthropic uses input_schema, MCP uses inputSchema, and Gemini only accepts a subset of JSON Schema — nullable stays a flag, and unsupported keywords are dropped with a warning.

    Where do path parameters and request bodies end up?

    All inputs are flattened into one object schema: path and query parameters keep their names (header params are prefixed in the description), and request-body properties are merged in. If a body field clashes with a parameter name it is renamed to name__body rather than silently overwriting — that is a real bug in some open-source converters.

    Is my spec uploaded or stored?

    The spec is sent to this site's own conversion endpoint, converted in memory and discarded — nothing is stored or logged. The page never calls third-party services.