Free tool
OpenAPI to MCP tools converter
Quick answer
Paste an OpenAPI 3 spec in JSON and this converter turns every operation into an MCP tool definition: a name, a description, an input schema built from its parameters and request body, and annotations marking it read-only, a write or destructive. GET reads, DELETE is destructive, and everything else writes. Nothing leaves your browser.
How each operation is converted
- Name: the operationId, or the method and path when there is none.
- Description: the summary and description, which is what the model reads to decide when to call it.
- Input schema: path and query parameters plus the JSON request body, with local $ref references resolved.
- Annotations: GET and HEAD are read-only, DELETE is destructive, and everything else is a write. PUT is marked idempotent.
Review before you ship it
The method is a starting point, not the truth: plenty of APIs delete on POST. Read the risk column and change any tool that is wrong, because clients decide what to confirm with the user from these annotations. Then cut the list down to what users actually ask for, and rewrite descriptions for a model rather than a developer.
If you would rather not run the tools yourself, Verb takes the same idea further: the agent sits inside your product, calls your API as the signed-in user, and asks before anything that changes data. Adding an AI agent to your website covers what that involves.
Frequently asked questions
How do I turn an OpenAPI spec into MCP tools?
Each operation becomes one tool. Its operationId becomes the name, its summary the description, and its path, query and body parameters the input schema. Mark each tool as read-only, a write or destructive so the client knows which ones need a person's approval.
Should every API endpoint become an AI agent tool?
No. Expose the operations a user would actually ask for, with descriptions written for a model rather than a developer. A hundred tools with terse descriptions make an agent worse at choosing the right one.
What are MCP tool annotations?
Hints a server gives about a tool's behaviour: readOnlyHint for tools that change nothing, destructiveHint for ones that can delete or overwrite, idempotentHint for ones safe to repeat. Clients use them to decide what to confirm with the user, and treat them as untrusted unless the server is.
Does this support YAML or Swagger 2?
It reads OpenAPI 3 in JSON. Convert YAML to JSON first, and upgrade a Swagger 2 spec to OpenAPI 3 with a converter such as the one in Swagger Editor.