Best AI Agent Skills for API Design and OpenAPI (2026)
A. Frans
Published August 5, 2026
Table of Contents
Quick Answer
Half the confusion in this category comes from four projects with nearly identical names doing three different things.
Three of them convert an OpenAPI specification into an MCP server, so an agent can call your existing REST API as tools. One of them does the reverse, wrapping MCP tools behind an OpenAPI-compatible HTTP endpoint so ordinary software can call them. People install the wrong one, watch nothing work, and conclude the category is broken.
Here's the sorting rule. If your API already exists and you want an agent to use it, you want a spec-to-MCP converter. If your agent tools already exist and you want a web app to call them, you want the proxy. Everything below follows from that.
The shortlist
| Skill | Direction | Maintainer | Licence | Directory status |
|---|---|---|---|---|
| openapi-mcp-server | Spec to MCP, optimised for large specs | janwilmake | MIT | Community, updated July 2026 |
| mcp-openapi-server | Spec to MCP resource | ivo-toby | MIT | Community, updated June 2026 |
| openmcp | Spec to MCP, tool subsetting | getdatanaut | MIT | Community, last update August 2025 |
| mcp-link | OpenAPI v3 to MCP | automation-ai-labs | MIT | Community, last update April 2025 |
| mcpo | MCP to OpenAPI proxy | open-webui | MIT | Verified, updated May 2026 |
| MCP Builder | Build a server from scratch | Anthropic | MIT | Official, updated July 2026 |
| Hono | Implement the API itself | honojs | MIT | Verified |
| Data API Builder | Database to REST, GraphQL, and MCP | Azure | MIT | Verified |
| Grafbase | GraphQL federation gateway | Grafbase | MPL-2.0 | Verified |
Spec to MCP: pick on spec size, then on maintenance
All three converters take an OpenAPI document and produce callable tools. The differences that matter in practice are how they handle a spec too large to fit in context, and whether anyone still maintains them.
openapi-mcp-server is built around the large-spec problem. Its stated purpose is letting an AI wade through complex OpenAPI documents in plain language rather than loading every path as a separate tool. That constraint is the one people hit first. A real enterprise spec has hundreds of operations, and naively converting each one into a tool blows past any sensible tool budget and makes the agent worse at choosing. Being able to search the spec and then call the operation is the right shape. It's community tier, MIT, and our directory records an update in July 2026, which makes it the most actively maintained of the three.
mcp-openapi-server takes a different position: turn the specification into an MCP resource rather than a pile of tools. Resources are read material, tools are actions. Exposing the spec as a resource means the agent reads the contract and then decides, which composes well when you already have a separate HTTP tool. Maintained by ivo-toby under MIT, updated June 2026.
openmcp converts a spec into a server with only the tools you select, which is the manual answer to the same bloat problem openapi-mcp-server solves automatically. Good idea, and the directory shows no update since August 2025. A year of silence in a protocol that changed several times in that window is a real risk, not a stylistic quibble.
mcp-link converts any OpenAPI v3 API to an MCP server and shows a last update of April 2025. Treat it as a reference implementation to read rather than a dependency to install.
The honest summary: start with openapi-mcp-server, fall back to mcp-openapi-server if you prefer the resource model, and read the other two rather than running them.
mcpo goes the other way and people keep missing it
mcpo is an MCP-to-OpenAPI proxy from the Open WebUI team, MIT licensed, verified tier, updated May 2026. It takes MCP servers you already run and exposes them behind a standard HTTP interface with an OpenAPI description.
This matters more than its name suggests. MCP is a protocol between an agent and its tools. It is not a general web API, and anything that isn't an MCP client cannot talk to it. The moment you want a dashboard, a cron job, or a mobile app to trigger the same capability your agent uses, you either rebuild the tool as an HTTP service or you put a proxy in front. mcpo is the proxy, and it means one implementation serves both consumers.
It also solves an authentication problem quietly. Standard HTTP in front of your tools means standard API keys, standard rate limiting, and standard logging, instead of whatever your MCP transport happens to support.
Designing the API in the first place
If you're building the service rather than wrapping one, two skills earn their place.
MCP Builder is Anthropic's official skill for producing production MCP servers, covering schemas, error handling, authentication, and testing. It generates TypeScript. Even when you're implementing in another language, the schema and error-handling conventions it enforces are the closest thing to a house style for the protocol, and getting those wrong is the most common reason a hand-rolled server behaves badly under an agent.
Hono covers the HTTP side: routing, middleware, request validation, OpenAPI spec generation, and deployment to Cloudflare Workers, Deno, Bun, or Node. The spec generation is the part that matters for this article. An API whose specification is generated from the same validators that enforce requests at runtime cannot drift, and spec drift is what breaks every converter above. Hand-maintained OpenAPI files are wrong within a month.
Data API Builder from Azure is worth knowing about even outside the Azure estate. It generates REST endpoints, GraphQL endpoints, and MCP tools from a database schema, which collapses three layers into configuration. It's MIT licensed and actively maintained. The tradeoff is the usual one for schema-driven generation: your API surface becomes your table shape, which is fine for internal tooling and wrong for a public product API.
For GraphQL specifically, Grafbase handles federation at the gateway, and Apollo Client covers the consumer side with caching. Note Grafbase is MPL-2.0 rather than MIT, which is worth a glance from anyone with a licence policy.
Installing without the usual dead end
Most of this page is MCP servers, not skills in the instruction sense, and they install differently.
For an MCP server, register it with claude mcp add, using the command documented in that project's README, then confirm the connection with /mcp. Check the README rather than any single-line install string, including the ones in our own directory. Entry points move and these are small projects.
For a skill pack distributed as a plugin, add the marketplace and install from it inside Claude Code: /plugin marketplace add owner/repo then /plugin install name.
For something you write yourself, create ~/.claude/skills/skill-name/SKILL.md. No install step.
One deployment note that saves an afternoon. A spec-to-MCP converter pointed at an authenticated API needs credentials at the converter, not at the agent. Put the key in the server's environment. Agents leak what's in their context, and an API key in a tool argument is a key in a transcript.
Security, briefly, because this category deserves it
Every converter here reads your OpenAPI document and then makes network calls to the API it describes. That's a broad capability. Three checks before you run one against anything real.
Read what the project sends. A converter should call the API described in the spec and nothing else. Any telemetry endpoint is a reason to stop.
Run it against a staging API first. If the spec includes destructive operations, the agent can now call them, and a DELETE exposed as a tool with a friendly name will eventually get called.
Prefer the maintained ones. This isn't fussiness. MCP's transport and auth story changed materially across 2025 and 2026, and a converter frozen in April 2025 predates most of it.
Our guide on auditing agent skills before installing covers the general version of this check.
FAQ
What's the difference between openapi-mcp-server and mcpo?
Direction. openapi-mcp-server turns your existing REST API into tools an agent can call. mcpo takes MCP tools you already have and exposes them over HTTP so non-agent software can call them. Installing one when you needed the other is the single most common mistake in this category.
Can an agent use my API without any of these?
Yes, if the API is small and you give the agent a generic HTTP tool plus the documentation. Converters earn their place when the spec has dozens of operations, or when you want each operation properly typed so the agent stops guessing parameter names.
Which converter handles a spec with 300 endpoints?
openapi-mcp-server, because it's designed around searching a spec rather than registering every path as a tool. Registering 300 tools degrades tool selection badly, regardless of context window size.
Is a stale converter dangerous, or just unmaintained?
Both, mildly. The immediate problem is compatibility, since MCP's transport and auth changed across 2025 and 2026 and an unmaintained server may not negotiate correctly. The secondary problem is that nobody is patching dependencies in a component that holds API credentials.
Should I generate my OpenAPI spec or write it by hand?
Generate it from the same validators that enforce requests at runtime, which is what Hono does. Hand-written specs drift from the implementation within weeks, and every tool on this page trusts the spec completely.
Do these work outside Claude Code?
The MCP servers do, since MCP is an open protocol with clients in several editors and agent frameworks. The plugin-distributed skill packs are Claude Code specific. Our comparison of agent skills, subagents, and hooks explains which layer is portable.
Share this article
📄Related Articles
Get More AI Tool Guides
New comparisons and guides every week. Join thousands of professionals staying ahead of the AI curve.