HAPI OpenAPI plugin

@mcp-com-ai/plugin-openapi lets HAPI turn an OpenAPI document into an MCP server. Each supported API operation becomes an MCP tool; your existing API continues to provide the business logic.

Install and serve

bun add -g @mcp-com-ai/hapi @mcp-com-ai/plugin-openapi

hapi serve --specs ./openapi.yaml --headless --port 3000
# Or use a remote document:
hapi serve --specs https://example.com/openapi.yaml --headless --port 3000

Connect an MCP-compatible client to http://localhost:3000/mcp.

You can also use the explicit command:

hapi openapi serve --specs ./openapi.yaml --mcp

hapi serve --specs detects OpenAPI automatically, so use that form when you want the same command for OpenAPI and HAPI Workflows (Arazzo). Install @mcp-com-ai/plugin-arazzo as well when you want to serve workflows.

The CLI pulls in Core and shared utilities for you. Keep this plugin and @mcp-com-ai/hapi on the same release version.

Preparing a ChatGPT App submission

For an installed Enterprise A2A plugin, add --a2a to preview the Agent Card instead of the MCP tool dump. --output json and --output yaml preserve the card fields; table (default) and markdown render readable summaries. Capability Graph planning adds the read-only capability_context and capability_plan skills when both graph and planning flags are enabled:

hapi serve --specs ./openapi.yaml --dry-run --a2a \
  --capability-graph --capability-planning --output json

Preview does not start an HTTP listener or verify that an OAuth broker will be available at runtime; check the live card for final OAuth publication.

hapi serve --dry-run computes the same MCP tool list a live server would expose via tools/list, then exits — no port bound, no OAuth/HTTP routes registered:

hapi serve --dry-run --specs ./openapi.yaml

With no --output flag, this prints a human-readable table: one row per tool, its readOnlyHint/destructiveHint/openWorldHint annotations, a description truncated to 27 characters, and the description's full length — plus a stats note below the table (total tool count and a rough estimated token count for the whole tool list) to help you spot an oversized tool list before it ships. Add --output json or --output yaml (kubectl-style; short form -o) to get the dump shaped like OpenAI's chatgpt-app-submission.v1.json schema instead:

hapi serve --dry-run --output json --specs ./openapi.yaml

Deterministic fields (tool names, descriptions, readOnlyHint/ destructiveHint) are filled in from the document. Fields that need actual understanding of the API — app_info.subtitle/description/category, each tool's justifications, test_cases, negative_test_cases — are left as greppable <PLACEHOLDER: ...> markers rather than guessed values.

openWorldHint is a special case: it's filled in only when actually knowable — an explicit x-openWorldHint on the operation, or --headless mode, which defaults it to true since a headless server's backend is by definition an external system (pass --no-open-world if that backend is actually air-gapped or a bounded private workspace). Outside those cases it's left as a placeholder too (? in the table), since a wrong guess here is worse than asking a human to decide.

To complete those placeholders, pipe the dump to a coding agent and ask it to apply the bundled hapi-apps-dump skill:

hapi serve --dry-run --output json --specs ./openapi.yaml \
  | claude -p '/hapi-apps-dump complete the placeholders from the hapi serve dump'

The same works with codex or copilot -p — HAPI ships one canonical skill file (skills/hapi-apps-dump/SKILL.md in this repo, packaged into every CLI distribution) rather than a separate install procedure per agent; ask whichever coding agent you use to install or adapt it for itself.