OpenAPI to MCP Tool Draft Generator
Convert OpenAPI 3.0 and 3.1 specifications into Model Context Protocol (MCP) tool definition drafts in this page's tool workspace. Ordinary site requests, extensions, and managed-device services are separate paths.
About this openapi to mcp tool draft generator
This OpenAPI to MCP converter maps selected OpenAPI 3.x operations into MCP tool definition drafts. Parameters become an object inputSchema, request bodies remain under a body property, the first explicit 2xx JSON schema can become outputSchema, and operation risk is carried into annotations. JSON and YAML input are parsed locally in the browser.
Worked safe-selection example
A GET /users/{id} operation is selected by default and marked read-only. A DELETE operation is visible but requires explicit selection and receives a destructive risk annotation.
Path, query, and header parameters retain their descriptions. Colliding names are prefixed by location instead of silently overwriting one another.
How OpenAPI fields map into a tool draft
- operationId becomes the preferred basis for a stable tool name; missing or conflicting names require review.
- Path, query, and header parameters remain distinguishable instead of being flattened without context.
- A JSON request body is placed under body, preserving its schema and required fields where supported.
- Operation summaries and descriptions become tool guidance, so vague API documentation produces vague agent behavior.
- Read, write, and destructive HTTP operations receive different risk treatment; HTTP method alone cannot replace an application authorization policy.
Authentication is documented, not implemented
OpenAPI security schemes can indicate API keys, bearer tokens, OAuth, or other requirements, but this page never asks for or stores a credential. The generated definition does not obtain tokens, inject headers, refresh OAuth grants, or decide which user may invoke an operation. Implement those controls in the actual MCP server and keep secrets outside generated metadata.
A tool definition is not a running server
The result is a client-side tool definition draft, not a deployed server. It does not execute HTTP requests, store credentials, implement OAuth, retry failures, paginate responses, enforce approval, or deploy an MCP transport. Those responsibilities belong in reviewed server code and infrastructure.
MCP conversion limits
- Read operations are selected by default; writes and destructive actions require explicit selection.
- Local schema references are inlined with recursion limits for portability.
- External references, weak descriptions, large endpoint sets, and complex schemas produce review warnings.
- Client support for advanced JSON Schema features varies, so generated drafts must be tested with each intended MCP client.
OpenAPI Specification · Content owner: CZOA Tools · Review methodology
How to use it
- Paste a complete OpenAPI 3.x JSON or YAML document without credentials or private production examples.
- Analyze it and correct blocking errors or unresolved local references.
- Select only the operations an agent genuinely needs, paying special attention to writes and deletion.
- Generate and download the drafts, then implement authentication, HTTP execution, confirmations, error handling, observability, and client testing separately.
Frequently asked questions
How does OpenAPI to MCP create a draft?+
The live page accepts OpenAPI JSON or YAML, validates it, displays extracted operations for review, lets the user select operations and a confirmation parameter for mutations, then emits MCP tool declaration JSON. It does not create a server or execute requests.
Can you show an input and its result?+
For one GET /weather operation with required query city, the three-step page generated one getWeather tool. Its inputSchema declares city as string and the metadata labels the operation GET, /weather, read-only, and without authentication.
How are mutating operations treated?+
The review step identifies write operations and exposes an optional confirm_execution boolean injection. This is a declaration-level safeguard for a future caller; it is not transport, credentials, authorization, server-side confirmation, or enforcement against a deployed API.
What does an MCP declaration not prove?+
It does not prove tool invocation, remote API compatibility, token handling, side-effect containment, policy compliance, or an MCP server implementation. The output is metadata that still requires transport, authentication, authorization, and error handling.