AnythingMCP, a self-hosted gateway that turns enterprise APIs into MCP tools

The problem: an estate of APIs and no MCP servers

AnythingMCP is described as an open-source, self-hosted MCP gateway that turns any REST/OpenAPI, SOAP, GraphQL, OData or SQL system into MCP tools for Claude, ChatGPT and Copilot, without writing an MCP server.

The framing in the README is aimed at a specific situation. Most companies have no MCP servers yet. They have a REST API, an ERP, a SOAP service from 2009 and a database. That inventory of legacy interfaces is the problem the gateway addresses, and the word self-hosted matters as much as the conversion.

The scale is the headline number. It ships 508 ready connectors, among them SAP, Etsy, weclapp and Amazon Seller, and 23 of them need no API key at all. The package description names more specifically: SAP S/4HANA, SAP Business One, Odoo, Xentral, JTL-Wawi, Shopware, WooCommerce and Amazon Seller. That is a catalogue oriented towards European enterprise software rather than towards developer SaaS, which tells you the intended user is a company with an ERP rather than a startup.

The alternative to this project is writing an MCP server per API. Each one is a small program that translates operations into tool definitions, handles authentication and returns results the model can read. For one API that is a day of work; for forty it is a team and a maintenance burden that changes whenever the upstream API changes.

The licence is AGPL-3.0, and the repository badge says AGPL-3.0 while the package.json says AGPL-3.0-only, with a separate LICENSING.md and a LICENSE file. That combination is the single most consequential fact for a company evaluating it, because AGPL obliges you to offer source to users who interact with it over a network.

Getting a first instance running with Docker

The quickstart requires Docker 24 and openssl, and on macOS you start Docker Desktop first. No clone is needed, because the compose file is fetched directly:

mkdir anythingmcp && cd anythingmcp
curl -fsSLo docker-compose.yml \
  https://raw.githubusercontent.com/HelpCode-ai/anythingmcp/main/docker-compose.quickstart.yml
printf 'JWT_SECRET=%s\nENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env
docker compose up -d

The two secrets are generated with openssl rand -hex 32 and written to a .env file. The JWT_SECRET signs the sessions and the ENCRYPTION_KEY encrypts the connector credentials you store. The README is emphatic about keeping that file: ENCRYPTION_KEY decrypts the credentials you store, and losing it means every connector has to be re-credentialed. That is a single file holding the only copy of the key itself, so it needs to be in your secret management rather than on a laptop.

Then open http://localhost:3000 and register. The first account becomes admin, which is a bootstrapping pattern that works for a single operator and needs thought if you deploy it for a team, since whoever registers first holds the admin role.

Your MCP endpoint is http://localhost:4000/mcp and the API documentation is at http://localhost:4000/api/docs. The ports differ because the frontend and the backend run as separate processes behind one container, on 3000 and 4000 respectively.

The compose file binds to 127.0.0.1 on purpose, because nothing in front of it terminates TLS. The README is explicit that for an instance other people or a cloud AI client can reach, you should clone the repo and run ./setup.sh, which asks for a domain, gets certificates through Caddy, generates the secrets and sets the MCP auth mode. There is a separate Deployment Guide at docs/deployment.md.

How the three-step workflow works

The README lays out the flow in three steps, and the middle one is the interesting part.

The first step is adding a connector. You install an adapter from the catalogue, which is a ready JSON definition for SAP, Odoo, DHL and the rest, or you point AnythingMCP at your own OpenAPI spec, WSDL, GraphQL endpoint, Postman collection or database. Once configured in your workspace it becomes a connector, and each of its operations becomes an MCP tool.

The second step is deciding what the model sees. You rename and describe the tools in the visual editor, drop the fields that must not leave your network, and choose which roles may call which tools. This is the step that makes the gateway more than a translator, and it is where the security model lives.

The third step is handing one URL to your AI client. The MCP server is the endpoint you add to Claude, ChatGPT, Copilot, Gemini or Cursor. It exposes the connectors you assign to it, and nothing else.

That last phrase is the design's central promise. Instead of many MCP servers, each with its own configuration and its own credentials, you have one endpoint that presents a curated set of tools with a single access model.

The per-source table in the README shows how much of the translation work is done for you. For OpenAPI and Swagger you import a spec by URL or paste it, and every operation becomes a tool with parameters, auth and endpoint mapping filled in. A Postman collection or a cURL request imports with folders, auth, body modes and template variables carried over. A WSDL turns each operation into a tool with envelopes, parameter order and WCF services handled. GraphQL introspection turns queries and mutations into tools, or you define the operations yourself.

Repository shape, deployment options and the AGPL question

The repository is a Node workspace with packages/backend, packages/frontend and packages/cli, requiring Node 22.12 or newer in the engines field. The backend is NestJS and the frontend is Next.js, and the Dockerfile builds them into a single container running both on one Node runtime. The Node version is an ARG in the Dockerfile defaulting to 26-alpine, with a comment that the shipped image tracks a newer release than the local development minimum, and the install step allows a ten minute timeout for ARM64 emulation in CI.

There is a container registry on Docker Hub under helpcodeai, a glama.json file for the MCP directory ecosystem, and a CITATION.cff.

Deployment is offered in several shapes. There is the managed cloud, AnythingMCP Cloud, which the README describes as the same AGPL code operated in Frankfurt, Germany, with a seven-day free trial and a data processing agreement on request. There are one-click deploy buttons for Railway and DigitalOcean. SSO and SCIM are stated as self-hosted only, which is a sensible split for a product that hosts your API credentials.

The AGPL question deserves a direct answer rather than a note in the corner. AGPL-3.0 means that if you modify the software and let users interact with it over a network, you must offer them the corresponding source of your modified version. For an internal tool inside a company that most people never interact with directly, that obligation rarely bites. If you plan to expose a modified AnythingMCP to customers, the licence becomes the deciding factor, and the answer is that you need a commercial arrangement rather than the open source version.

The project is listed in the official Claude directory, has a badge for GitHub trending, and is described as a hacktoberfest topic. The release cadence is very fast, with v0.40.1, v0.41.0 and v0.41.1 all on the same day in October 2026, which is a signal of active development and also of a young project.

How this compares with writing MCP servers by hand

The alternative, and the one a small team should consider seriously, is to write the MCP server yourself for the two or three APIs that matter.

For a single REST API with an OpenAPI spec, an MCP server is a thin wrapper: read the spec, expose the operations as tools, forward the calls with the user's credentials. That is often a day of work, and the result is code you own with no licence constraints, no extra service and no credentials sitting in a database you did not build.

Where the gateway wins is breadth and governance. 508 connectors in one place, with a visual editor for trimming what the model sees, role based access, audit logs and a knowledge graph over the whole catalogue, is a different proposition from forty small services. The credential store in particular, with encryption at rest, is something most teams will not build for their internal tools, and the audit trail of what an agent called and when is the thing auditors ask about.

The third option is a hosted MCP server per service, from a vendor or from the API provider. That avoids the licence question entirely and the self-hosting work, at the cost of sending your data to a third party and of no unified access model.

The realistic reading is that AnythingMCP is for organisations with a wide internal API estate and a mandate to let agents use it. For a team with one API and no agents in production yet, the hand-written server is faster, simpler and carries no AGPL obligation.

Editorial conclusion

Adopt AnythingMCP if you have enterprise APIs that no one has wrapped as MCP servers and you need an agent to reach them with credentialed access, a visual way to trim what the model sees, and a self-hosted deployment you control. Do not adopt it if you need to modify and redistribute it under a permissive licence, because it is AGPL-3.0-only, or if you cannot keep the ENCRYPTION_KEY safe, since losing it means re-credentialing every connector. Verify first by running the quickstart compose file on loopback, registering the first account to become admin, and checking that one connector with read-only operations answers correctly before you assign anything write-capable to a model.

Frequently asked questions

Official sources

1. HelpCode-ai/anythingmcp on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases