emcee: an MCP server generated from any OpenAPI spec

The gap emcee fills between an OpenAPI document and an MCP client

MCP gives a model a standard way to discover and call tools. The catalogue of existing servers covers browsers, developer tools, and similar systems, but most internal or niche HTTP APIs have no server at all. emcee's premise is that an OpenAPI specification already describes every operation, parameter, and response shape those APIs expose, so the spec can be the server definition. The README frames the target user directly: services you are building yourself, where a web app with an OpenAPI spec might be enough without a dashboard or a client library. That is a narrower audience than "anyone with an API". It is for people who already treat the spec as the source of truth, not for teams whose documentation lives in a wiki.

How emcee turns spec operations into MCP tools

The binary takes a spec path or URL as its positional argument and starts an MCP server over stdio, using JSON-RPC 2.0 as the wire format. It listens on stdin, writes to stdout, and sends logs to stderr, which is why the Claude Desktop config only needs a command and an args array. Parsing is handled by github.com/pb33f/libopenapi, and the MCP side uses the official Go SDK, github.com/modelcontextprotocol/go-sdk. Request execution goes through hashicorp/go-retryablehttp, which is where the --retries and --timeout flags take effect. The weather.gov example in the README produces 57 tools, one per operation, which tells you the mapping is close to one-to-one with the spec's paths and methods rather than a curated subset. The README also points out that you can pre-process the spec with jq, yq, OpenAPI Overlays, or Redocly before handing it over, so trimming a large API down to a handful of endpoints is a shell pipeline problem, not a server feature.

Installing emcee and pointing Claude Desktop at a real spec

On macOS with Homebrew, installation is a single tap install. The README lists this as the quickest route.

brew install mattt/tap/emcee

For Linux x86-64, i386, and arm64, or macOS Intel and Apple Silicon, the installer script downloads a prebuilt release. The README gives the bash and zsh form, and a fish variant using psub.

sh <(curl -fsSL https://get.emcee.sh)

A prebuilt Docker image is also published, which is useful when you do not want the binary on the host. The README shows the interactive form.

docker run -it ghcr.io/mattt/emcee

If you prefer to build it, the source route needs Go 1.24 or later, matching the go directive in go.mod.

git clone https://github.com/mattt/emcee.git
cd emcee
go build -o emcee cmd/emcee/main.go

The first real use is registering a server in Claude Desktop's config file. On macOS that file sits in Application Support, and the README suggests opening it with code. The example below registers weather.gov, whose OpenAPI document is public.

{
  "mcpServers": {
    "weather": {
      "command": "emcee",
      "args": ["https://api.weather.gov/openapi.json"]
    }
  }
}

After saving, quit and reopen Claude. The README says a hammer icon with a count appears in the bottom right of the chat box; clicking it lists the tools emcee exposed. Asking about the weather in Portland, OR should prompt Claude to request one of those tools, which you approve or deny before any call is made.

Authentication flags, and the spec-fetch caveat that catches people out

emcee supports three header styles for the API it wraps: --bearer-auth produces an Authorization: Bearer header, --basic-auth produces Basic with a base64-encoded user:pass pair, and --raw-auth sets the Authorization header verbatim for anything else. Each flag also accepts a 1Password secret reference in the op://vault/item/field form, which requires the op CLI on PATH and an active sign-in before emcee or Claude Desktop starts.

The caveat is easy to miss. The README states plainly that emcee does not use auth credentials when downloading OpenAPI specifications from URLs given as command arguments. If the spec itself is behind authentication, you must fetch it with another HTTP client, save it locally, and pass the file path instead. That asymmetry is a real design boundary: the flags protect the API calls the model makes, not the retrieval of the document that defines them.

Where emcee is the wrong tool

Three cases stand out. First, no OpenAPI document means no server; emcee has nothing to generate from, and hand-writing an MCP server is the honest alternative. Second, a spec that requires authentication to download breaks the single-argument workflow, forcing the local-file detour above. Third, transport. emcee implements stdio only, so it is a per-client local process, not a shared network service you can host once for a team. Anyone expecting a long-running HTTP endpoint should look elsewhere.

There is also a scale question the README does not answer. A spec with hundreds of operations becomes hundreds of tools, and how an MCP client behaves when the tool list is that long is not documented. The README's own suggestion to filter with jq or yq is the practical mitigation, but it means maintaining a pipeline between your spec and your configuration. Finally, the README does not document rollback or version pinning for the installer script, so reproducibility depends on your package manager or on building from a tagged release yourself.

How emcee differs from hand-written MCP servers and hosted gateways

The obvious alternative is writing an MCP server with the official SDKs. That gives you control over tool naming, argument validation, and which operations are exposed at all. emcee trades that control for speed: if the spec already describes the surface you want, generation is minutes of work rather than days. The cost is that tool names and schemas follow the spec, and the only way to change them is to transform the document before emcee sees it.

A second comparison is against hosted MCP gateway products that accept an OpenAPI spec and expose a remote endpoint. Those remove the local binary and the per-machine config, at the price of sending your API credentials and traffic through someone else's infrastructure. emcee keeps the process on your machine and the credentials in your own flags or 1Password vault. Which matters more depends on whether your API is public or internal.

Maintenance, licence, and what upgrading costs

The repository is not archived, and the last push was on 2026-07-04. Release v0.8.0 landed on 2026-06-29, following v0.7.0 in October 2025 and v0.6.1 in August 2025. That cadence suggests slow, occasional releases rather than a fast-moving project, and the version number is still below 1.0, so flag and config behaviour can shift between minor versions. The dependency list includes a pseudo-version of the MCP Go SDK (v0.2.1-0.20250814153251-bb6dadecca24), which means the SDK is pinned to a commit rather than a tagged release; expect that pin to move as the SDK stabilises.

emcee is MIT licensed, so you can use, modify, and redistribute it, including in commercial settings, provided the copyright notice and permission notice are preserved. That is the whole of the licence implication here; anything beyond it depends on your own legal review.

Editorial conclusion

Adopt emcee if you already maintain an OpenAPI document and want an MCP client to call it without writing a server by hand, particularly for an internal service you control. Skip it if your API has no spec, if the spec needs authenticated access at download time, or if you need a long-running shared server rather than a local stdio process. Before wiring it into Claude Desktop, check three things: that the spec parses under libopenapi, that the tool names it produces are ones you are happy to expose, and how you will handle credentials, since the README warns that auth flags are not used when fetching the spec itself.

Frequently asked questions

Official sources

1. License: MIT
2. mattt/emcee on GitHub
3. Project website
4. README
5. Releases