No manual wrappers
Import a Swagger/OpenAPI JSON or YAML URL and generate MCP-compatible tools from operation metadata instead of writing and hosting a custom MCP server per API.
OpenAPI to MCP
Convert Swagger and OpenAPI specs into MCP tools
Swagger to MCP Gateway imports an OpenAPI URL, generates MCP tools from REST operations, lets you edit descriptions and hide unsafe endpoints, then publishes a Gateway-routed MCP URL for AI clients. Your API does not need to change, and clients do not need upstream credentials.
No credit card required.
SwaggerOpenAPIAPI to MCPEditable descriptionsGateway Chat
app.swaggertomcp.com/publish
Swagger to MCP
OpenAPI to MCP publish flow
Import OpenAPI source
https://api.example.com/openapi.json
Generated tools
18 selectedget_order_by_id
GET /orders/{id}
create_support_ticket
POST /tickets
search_customers
GET /customers/search
MCP endpoint
/mcp/acme-orders
Claude, Cursor, VS Code, or Gateway Chat can discover the selected API tools.
Auth policyServer-side
LogsRedacted
Why it matters
A production boundary for API tools
A hand-written MCP adapter can be enough for one demo. It becomes harder when every API needs auth handling, tool descriptions, limits, redacted logs, and a way to hide unsafe operations.
LLM-friendly descriptions
Rewrite generated descriptions so the tool says what it does, when to use it, which inputs matter, and what the result means.
Redacted logs
Inspect tool calls, latency, success rates, failures, and response payloads while sensitive request and response values are masked before storage.
Use cases
Connect existing REST APIs to AI workflows
Use OpenAPI to MCP when your application already has useful HTTP APIs and you need a smaller, safer, model-facing tool layer.
Internal operations APIs
Expose selected service, ticketing, order, or support actions to AI assistants without publishing the whole internal API catalog.
Customer-facing SaaS APIs
Offer an MCP endpoint for product workflows while keeping account limits, published tool state, and upstream credential policy in the Gateway.
Developer demos
Turn a public or sample OpenAPI spec into a working MCP surface for evaluations, demos, and agent workflow tests.
Curation
Do not publish the whole API by default
An OpenAPI file often contains endpoints that are useful for developers but bad as AI-callable tools. The MCP catalog should be smaller than the full REST API.
Start with read or low-risk actions
Begin with search, lookup, status, reporting, or support helper endpoints. Add write actions only after the tool description and logging behavior are clear.
Hide broad admin endpoints
Do not expose user-delete, token-management, permission-changing, refund, or bulk-update endpoints just because they exist in the OpenAPI document.
Test the catalog in chat
Use Gateway Chat to ask realistic questions and see whether the model chooses the intended published tool with useful arguments.
Before / after
What an OpenAPI operation becomes
The upstream REST API stays the same. The Gateway creates an AI-facing MCP tool with a clearer name, typed arguments, a better description, and a server-side route to the original operation.
| API operation | Published MCP tool | Why it helps agents | |
|---|---|---|---|
| Search orders | GET /orders with query parameters such as customerId, status, fromDate, and limit. | search_orders: Search approved orders by customer, status, or date range before support follow-up. | The AI client sees a task-oriented tool and typed inputs instead of raw route details or upstream credentials. |
| Create support ticket | POST /tickets with a request body containing customerId, subject, priority, and message. | create_support_ticket: Create a support ticket after the user confirms the customer and issue summary. | The published description can explain when the write action is allowed and which arguments must be present. |
| Customer status | GET /customers/{id}/status using a path parameter and upstream bearer authentication. | get_customer_status: Read the current customer status and account flags for a specific customer ID. | The Gateway keeps upstream auth server-side while the MCP client gets a narrow lookup tool. |
Agent-ready descriptions
Generated tools should be edited before real use
The OpenAPI document gives the Gateway a starting point. The published MCP catalog works better when descriptions are written for tool choice, not only for human API documentation.
Weak description
Bad example: Gets orders. This is too vague; it does not tell the model when to use the tool, which filters matter, or what result to expect.
Agent-ready description
Better example: Search approved orders by customer, status, or date range before support follow-up. Use limit to keep the result small.
Visibility control
Only published tools appear in tools/list. Keep destructive, broad, internal, or confusing operations hidden until there is a clear workflow.
Gateway routing
MCP clients call the Gateway MCP URL. The Gateway checks publication state, account limits, credential policy, and redacted logging before forwarding to the REST API.
Workflow
From source to MCP endpoint
The Gateway keeps source discovery, publishing, execution, and monitoring separated so the AI-facing surface stays controlled.
Step 1
Import the OpenAPI source
Paste the Swagger/OpenAPI JSON or YAML URL, confirm the base URL, and add upstream bearer or API key auth if the API requires it.
Step 2
Review generated tools
Inspect generated operation tools, hide unsafe endpoints, and improve tool and parameter descriptions before publishing.
Step 3
Test and connect the MCP endpoint
Test the surface in Gateway Chat, then use the generated MCP URL with Claude, Cursor, VS Code, or any compatible MCP client.
FAQ
Common questions
Short answers for teams comparing MCP adapters, API gateways, and database access for AI agents.
Is this an OpenAPI generator or an MCP gateway?
It is both for the OpenAPI flow. The Gateway reads OpenAPI metadata, generates MCP tool definitions, lets you curate the published catalog, enforces account limits, and routes tool calls to the upstream REST API.
Do AI clients need my upstream API key?
No. In the recommended mode, clients authenticate to the Gateway and the Gateway injects encrypted upstream credentials server-side.
Can I choose which endpoints become tools?
Yes. Generated tools can be published or hidden individually. Use this to keep the MCP catalog focused on the operations an AI workflow should actually call.
Are both Swagger and OpenAPI supported?
Yes. The OpenAPI flow accepts Swagger/OpenAPI JSON or YAML URLs and uses the document metadata to create operation-derived MCP tools.
Does every endpoint automatically become a published MCP tool?
No. The Gateway can generate tools from OpenAPI operations, but the published surface is curated. You can hide unsafe or unnecessary operations before using the MCP endpoint.
Does OpenAPI to MCP change my existing API?
No. The Gateway sits in front of the API. It creates an MCP-facing surface and forwards allowed tool calls to the existing REST operation without requiring the upstream API to become MCP-aware.
Can tool descriptions be edited for agent-ready behavior?
Yes. Tool descriptions can be customized so the MCP catalog is more agent-ready. Good descriptions explain the purpose, when to use the tool, important inputs, and expected result.
Should write or destructive endpoints be published?
Only when there is a clear workflow and policy. Start with narrow read or low-risk actions, then publish write actions deliberately after testing descriptions, arguments, and logs.
Can I test the generated tools before using Claude or Cursor?
Yes. Gateway Chat can use the published MCP surface so you can test tool choice, argument quality, and responses before connecting external MCP clients.
What happens if the OpenAPI spec changes?
The Gateway reads the OpenAPI document during the publish/import flow and stores generated tools for the integration. When the upstream spec changes, review and republish or update the integration so the MCP surface reflects the intended operations and descriptions.
Can this be used with public and internal APIs?
Yes. Public APIs can be used for demos and prototypes, while internal APIs can be published behind Gateway authentication so AI clients do not receive broad upstream credentials.
Do OpenAPI tool calls go directly from the AI client to my API?
No. MCP clients call the Gateway MCP endpoint. The Gateway checks integration state, account limits, publication state, credential policy, and logging rules before forwarding the request to the upstream REST API.
What makes this different from exposing an OpenAPI file to an agent?
An OpenAPI file describes many routes. A Gateway-published MCP surface exposes a smaller tool catalog with edited descriptions, hidden endpoints, Gateway-managed credentials, limits, and redacted observability.