We Converted 300 Public OpenAPI Specs to MCP Tools. Here Is What Broke.

Short answer: on 5 October 2026 we pointed Gatana at 300 public OpenAPI and Swagger specifications sampled from apis.guru. 262 converted into MCP tools on the first run (87%). 37 of the 38 failures were caused by our own converter, not by the specs. After fixing it the same day, 299 of 300 convert (99.7%), every operation becomes a tool, and the median tool schema is 1.4 KB instead of 11 KB.

What we measured

The question we wanted a number for: if you have a REST API with an OpenAPI description, how likely is it that an MCP gateway turns it into working tools without anyone writing wrapper code?

• Sample. The apis.guru directory listed 2,529 APIs that day. We drew 300 at random with a fixed seed (20261005), taking each API’s preferred version: 178 OpenAPI 3.x and 122 Swagger 2.0 documents from 113 providers. Azure, AWS and Google APIs make up about half, because they make up about half of the directory.
• Procedure. For each spec, a script created an OpenAPI server in a Gatana organization, pointed it at the spec URL, refreshed the tool cache (which is where conversion happens), read the resulting tools, and deleted the server. Four specs ran in parallel. The whole run took 82 seconds the first time and 46 seconds the second.
• What we recorded. Whether conversion succeeded, the error if not, the number of operations in the spec versus tools produced, the size of each generated input schema, tool name lengths, and conversion time.
• Where. A local Gatana instance at the code of that day. Conversion does not depend on the environment.

The per-spec results of both runs are in one file: openapi-to-mcp-2026-10-05.csv.

First run: 87% converted

	Swagger 2.0	OpenAPI 3.x	All
Specs	122	178	300
Converted	121 (99.2%)	141 (79.2%)	262 (87.3%)

In every converted spec, 100% of the operations became tools: 6,964 tools in total, a median of 7 per spec and a maximum of 386 (NetBox). Conversion took a median of 0.2 seconds per spec and at most 8 seconds.

The gap between 2.0 and 3.x was the first signal that the failures were ours. Swagger 2.0 is the older and simpler format. If specs were the problem, the newer format with stricter tooling should not fail five times as often.

Why 38 specs failed

We classified every error.

Cause	Specs	Whose problem
A response schema whose root is not an object. MCP requires outputSchema to be an object, and the converter rejected the whole server instead of dropping that one output schema	19	Ours
A pattern regular expression that is valid in the spec but does not compile under JavaScript’s u flag, for example \p{Print}+	9	Ours
OpenAPI 3.0 nullable: true on a schema with no type, common in generated specs	7	Ours, by being too strict
Draft-04 style boolean exclusiveMinimum	2	Ours, by being too strict
A webhook-only document with no paths object	1	The spec

So 37 of 38 failures were avoidable on our side. The converter now drops a non-object output schema instead of refusing the server, validates patterns without the u flag, accepts nullable without type, and reads the draft-04 keywords.

Second run, same 300 specs: 99.7% converted

	Swagger 2.0	OpenAPI 3.x	All
Converted	122 (100%)	177 (99.4%)	299 (99.7%)

The one remaining failure is the Adyen webhook specification, which has no paths and therefore no operations to convert. The second run produced 10,834 tools, 56% more than the first, because large specs that failed before now convert. The largest is GitHub’s REST API with 845 tools from one document. Again every operation became a tool, in a median of 0.15 seconds per spec and at most 3.7 seconds.

The hidden cost: schema size

Conversion success is not the whole story. An MCP client receives every tool’s input schema on every session, and those schemas count against the context window.

	First run	After the fix
Input schema per tool, median	11,276 bytes	1,424 bytes
Input schema per tool, 90th percentile	94,668 bytes	4,808 bytes

The first-run numbers came from copying the whole $defs section of a spec into every tool. A tool that used one of 1,024 definitions carried all 1,024. The converter now keeps only the definitions a tool actually references.

Gatana’s own API, exposed the same way, shows what that means in tokens. Before the fix, its 149 tools cost 5.12 million tokens of definitions (tiktoken o200k_base, name plus description plus input schema as compact JSON), about 34,000 per tool, which no client could load. After it, 180 tools cost 43,782 tokens, about 240 per tool. That is 140 times less per tool.

Tool names

MCP clients commonly limit tool names to 64 characters, and a gateway prefixes each name with the server’s slug. In the second run, 84 of 10,834 generated names (0.8%) exceed 64 characters on their own, and 200 (1.8%) exceed 56, which is the room left after an 8-character prefix. The long ones come from Azure and AWS operation IDs. If your API is one of those, give the server a short slug or override the few names.

What this means for you

• If your API has a Swagger 2.0 or OpenAPI 3.x description, converting it to MCP tools is a solved problem. Expect every operation to become a tool, and expect the conversion to take under a second.
• Check your pattern fields and nullable usage if a converter rejects your spec. They were the two most common spec-side quirks, and a good converter should tolerate both.
• Ask how big the generated schemas are. A converter that inlines all definitions into every tool can make a 200-tool API cost millions of tokens per session. The median should be in the low kilobytes.

Reproduce it

The sample, both result sets and the error texts are in the CSV. To repeat the run on your own Gatana organization: create an OpenAPI server with the public API, set transportConfig.specUrl, call the tool refresh endpoint, and read the server’s tools. The OpenAPI server documentation describes each step. We will re-run this sample when the converter changes and update the numbers here, with the date.

This run is listed with our other measurements, each with its date and raw data, on the measurements page.