Swagger to MCP Tools: Import a Swagger 2.0 Spec As It Is

Plenty of working APIs are still described in Swagger 2.0, and they do not need a migration before an AI client can use them. GetMCP’s Swagger to MCP tools import reads a swagger: "2.0" document as it is, lists every operation, and turns the ones you choose into MCP tools for Claude, ChatGPT or Cursor.

This guide is for teams running older services, internal APIs and vendor platforms that publish a Swagger file. It focuses on what is specific to Swagger 2.0: how the base URL is built, how in: body and formData parameters are handled, and what to check after the import.

What is Swagger 2.0 import?

Swagger 2.0 is the version of the API description format that came before OpenAPI 3. GetMCP has a dedicated importer for it, separate from the OpenAPI 3.x importer, so you do not have to convert the file first. Each operation under paths becomes one candidate tool, for the GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS methods.

Open a server’s Tools tab, click Import Tools and choose From Swagger 2.0, or click Add Tool and pick the From Swagger 2.0 card. The importer accepts JSON or YAML.

How Swagger to MCP tools import works

1. Choose a source. In the Import from Swagger 2.0 dialog, pick Paste text, Upload file (.json, .yaml or .yml, up to 10 MB) or Fetch from URL.
2. Click Parse. The document must say "swagger": "2.0" exactly. A document that declares openapi instead is turned away with a hint to use the OpenAPI importer.
3. Review the operations. Every operation is listed with its method, tool name and full URL, and every one starts ticked. Untick the ones the AI should not use.
4. Pick the options. On conflict chooses between Skip existing and Create duplicate. After import chooses between Keep as draft and Activate now.
5. Import. The result screen counts the tools created, skipped and failed.
6. Finish the server. Add the API credential on the Authentication tab, review names and descriptions, test, and activate.

How Swagger 2.0 fields map to tools

Naming, descriptions and tags work the same way as in an OpenAPI import. The Swagger-specific parts map like this:

In the Swagger document	In the MCP tool
schemes, host, basePath	The base URL: the first scheme listed (https when none is), the host, then the base path.
summary, else operationId, else method and path	The tool name. “Create an order” becomes create_an_order.
description, else summary	The tool description.
Path, query and header parameters	Parameters with the type, description and default written inline on the parameter. Path parameters are always required.
A header parameter with a single enum value	A fixed header on every call.
The in: body parameter’s schema	Body parameters, one per property. Nested objects are flattened to dotted names and allOf is merged.
formData parameters	Ordinary parameters with no form encoding (see the gotchas below).
Local $refs such as #/definitions/Order	Resolved, so shared models arrive complete.
securityDefinitions	Listed in the preview (basic, apiKey and oauth2), not configured for you.

For example, a document with "host": "api.northwind.example", "basePath": "/v1" and "schemes": ["https"] gives a POST /orders operation the endpoint https://api.northwind.example/v1/orders.

Use cases

Bring a legacy internal service into the AI client

An operations team has a stock service whose framework still generates Swagger 2.0. A Swagger to MCP tools import of that file, limited to the read operations, puts the service in Claude with no change to the service itself.

Flow: swagger.yaml → import read operations → get_stock_level → stock service

Look up payments on an older gateway

A shop’s payment provider documents its API in Swagger 2.0. The finance lead imports only the transaction lookup operations, so the assistant can answer “did Amelia Okafor’s payment clear?” but cannot refund anything.

Flow: Chat question → get_transaction → payment gateway API

Maintain a client’s older API for an agency

An agency looks after Northwind’s ordering API, last documented in Swagger 2.0. It imports the spec into a server for that client and later adds new endpoints with a second import using Skip existing.

Flow: Northwind Swagger file → client server → client team in Cursor

Query device status from a management platform

A facilities team’s device platform exposes a Swagger 2.0 API. Imported tools let staff ask which sensors are offline and pull the last reading for a room.

Flow: “Which sensors in Building B are offline?” → list_devices → device API

Give a support assistant read access to an ERP

A support team imports the customer and invoice lookups from their ERP’s Swagger document. Agents check a customer’s open invoices from the AI client during a call.

Flow: “Open invoices for Acme Ltd” → list_invoices → ERP API

Tips and gotchas

• Form fields are sent as JSON. formData parameters get no form encoding. On POST, PUT and PATCH they go into a JSON body; on other methods they go into the query string. Test any endpoint that only accepts form posts or file uploads, and expect to rework it.
• No host means a relative URL. A document without host produces tools that start with the base path only, flagged with a warning. Add the scheme and host to each tool before you test.
• The security note uses the raw scheme names. The preview lists entries such as http:basic or apiKey:api_key. Match them on the server’s Authentication tab.
• Re-importing does not update tools. Existing tools are skipped or duplicated, never changed in place.
• Only local references resolve. $refs into other files are skipped with a warning.
• Check camelCase names. An operation without a summary is named from its operationId, and getOrder becomes getorder. Rename it in the Tool Editor if that reads badly.

Related features

• OpenAPI 3.0 and 3.1 import: the same flow for newer specs, with request bodies and 3.1 type lists.
• The Tool Editor: fix URLs, rename tools and add response selectors after the import.
• API authentication: set the credential your securityDefinitions call for.

FAQ

Do I need to convert Swagger 2.0 to OpenAPI 3 first?

No. GetMCP reads swagger: "2.0" documents directly with its own importer. A document that declares OpenAPI 3.0 or 3.1 goes through the OpenAPI importer instead.

Which Swagger versions are supported?

Only 2.0. Any other value in the swagger field is rejected with a message naming the version it found.

Do I have to import every operation?

No. Every operation is listed with a checkbox before anything is created, so you can leave out write or admin operations the AI should not use.

Will the imported tools work with the API’s authentication?

Yes, once you add the credential. The import lists the securityDefinitions it found but does not store a key. Enter it once as the server-stored API credential and every imported tool sends it.

See the full mapping on the Swagger to MCP server page, then import your document as drafts and test each tool before you switch it on.