anythingmcp
This server provides a read-only, informational interface to AnythingMCP, a self-hosted no-code MCP gateway, helping you learn about, deploy, and connect it to AI clients.
anythingmcp_overview — Returns a concise product overview of AnythingMCP with links to the website, GitHub repo, and cloud version.
anythingmcp_get_started — Gives copy-pasteable steps to install and self-host AnythingMCP via Docker (~60 seconds) or use the managed cloud.
anythingmcp_connect_client — Provides plain-text setup instructions for connecting one AI client (Claude, ChatGPT, Gemini, Copilot, or Cursor) to an existing AnythingMCP instance.
anythingmcp_list_connectors — Lists the 258 pre-built connectors (logistics, ERP, e-commerce, HR, public data, banking, messaging, sports) and the 5 no-code connector types (REST, SOAP/WSDL, GraphQL, Database, MCP-bridge).
All tools are read-only, idempotent, and have no side effects.
Connects to DATEV's tax and accounting platform for financial data operations.
Integrates with Deutsche Bahn's API to provide train schedule and ticket information.
Provides DHL shipment tracking capabilities using the Unified Tracking API.
Provides DPD parcel tracking capabilities using public data without requiring an API key.
Provides geocoding and location services via HERE Geocoding API.
Connects to Personio HR management platform for employee data and workflows.
Integrates with Shopware 6 e-commerce platform for product, order, and customer management.
Claude answering a question no chatbot could answer, because the data lives in a field-service system that speaks REST, not MCP:
Run it yourself — three lines, no clone, details below:
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 # → http://localhost:3000Three words appear throughout and mean three different things:
an adapter is one of the 259 JSON definitions that ship in this repo — SAP Business One, Odoo, weclapp, Xentral, Shopware, WooCommerce, Amazon Seller, DHL and the rest. 21 of them need no API key at all; the others ask for your credentials at import.
a connector is an adapter, or your own OpenAPI spec / Postman collection / WSDL / GraphQL endpoint / database, once you have configured it in your workspace. Anything you can point at, in minutes, without writing an MCP server.
an MCP server is the URL you hand to Claude. It exposes the connectors you assign to it, and nothing else.
Everything runs on your infrastructure, so you decide what leaves it. Per-tool response mapping declares which fields ever reach the model; credentials are AES-256-GCM at rest; the audit log keeps the full upstream response on your side. OAuth2, RBAC, SSO and SCIM are in the self-hosted build, not held back for a paid tier.
In production at KOCH Freiburg GmbH, where it connects AI assistants to 15+ internal systems — ERP, CRM, SOAP services and on-prem databases. AnythingMCP was extracted from that system by helpcode.ai in Freiburg, Germany, and open-sourced because an adapter catalog grows faster as a community than as a product.
Run it yourself
The recommended path, and the one measured below. Requires Docker 24+ and openssl; on macOS, start Docker Desktop first.
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 -dOpen http://localhost:3000 and register — the first account becomes admin.
Keep the generated
.env.ENCRYPTION_KEYis what decrypts the credentials you store. Lose it and every connector has to be re-credentialed; back it up wherever you keep your other secrets.
Service | Default URL |
Web UI |
|
MCP endpoint |
|
Swagger docs |
|
Measured on amd64: 31 s to pull the image, 24 s to a healthy API and a login page. The published image is amd64 only for now — the compose file pins the platform so it also runs on Apple Silicon under Docker Desktop's emulation, where the same boot took 24 s on an M-series laptop but can take a few minutes on older hardware.
The quickstart binds to 127.0.0.1 on purpose: nothing in front of it terminates TLS. For an instance other people or a cloud AI client can reach, clone the repo and run ./setup.sh — it asks for a domain, gets certificates through Caddy, generates the secrets and sets the MCP auth mode. See the Deployment Guide.
AnythingMCP Cloud is the same AGPL code, operated by us in Frankfurt, Germany. Start there to see it work on your own APIs without provisioning anything, and move it in-house when you want the credentials to stop travelling — the connectors are the same either way. DPA/AVV on request via info@helpcode.ai. SSO and SCIM are self-hosted only.
Related MCP server: MCPJungle mcp gateway
Connect any system
Most companies have no MCP servers yet. They have a REST API, an ERP, a SOAP service and a database. Each of them becomes a set of MCP tools, and one MCP server URL hands them to Claude, ChatGPT or Copilot.
OpenAPI / REST API to MCP
Import an OpenAPI 3.x or Swagger 2.0 spec, by URL or by pasting it, and every operation becomes an MCP tool with its parameters, auth and endpoint mapping filled in. Rename and describe the tools in the visual editor so the model picks the right one. REST connector docs · guide · 5-minute demo: openapi-to-mcp
SOAP / WSDL to MCP
Point AnythingMCP at a WSDL and each SOAP operation becomes a tool: envelopes, parameter order and WCF services are handled for you, with Basic, Bearer or API-key auth. That is how a SOAP service from 2009 ends up in front of a 2026 model, in minutes rather than weeks. SOAP connector docs · guide · 5-minute demo: soap-to-mcp
SQL database to MCP
PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite and MongoDB. The connector generates schema, example and query tools; you decide whether the model writes SQL or only fills in the parameters of queries you wrote. Query tools are read-only by default: AnythingMCP runs a single SELECT and blocks writes and stacked statements. Add a read-only database user and a role that sees only the tools it needs. Database connector docs · guide · 5-minute demo: sql-to-mcp
GraphQL to MCP
Introspection turns the queries and mutations of a GraphQL endpoint into MCP tools, or you define the operations yourself. GraphQL connector docs · guide
Postman collection to MCP
Import a Postman v2.1 collection: folders, auth, body modes and {{variables}} carry over, and every request becomes a tool. cURL commands work the same way. Postman import docs
ERP connectors
Ready adapters for the ERPs behind most order, stock and invoice questions. Install one, add your credentials, and the tools are live on your MCP server. Each name links to its setup guide.
System | Market | Tools | What the AI can do |
Global | 12 | Business partners, items, orders, invoices, quotations, deliveries; create sales orders | |
Global | 15 | Business partners, sales and purchase orders, billing documents, deliveries, journal entries | |
Global | 11 | Any model: partners, sales orders, invoices, products; create and update | |
Global | 6 | Any published OData page: customers, items, sales orders; create and update | |
Global | 11 | Any DocType: customers, sales orders, invoices, items, stock | |
Global | 10 | Third parties, invoices, orders, proposals, products, stock | |
JTL-Wawi † | DE | 9 | Items, stock per warehouse, customers, sales orders, shipments |
DE | 7 | Articles, customers, sales orders, invoices, stock | |
DACH | 11 | Customers, sales orders, invoices, articles, quotations, opportunities | |
Sage 100 † | DE | 6 | Addresses, items, sales documents, any Web API entity |
DE | 7 | Customers, stock items, sales orders, invoices, shipments | |
DE | 6 | Contacts, invoices, projects, tasks | |
NL | 6 | Any GetConnector: debtors, invoices, employees | |
IT | 6 | Anagrafiche, documents, items | |
IT | 6 | Customers, suppliers, invoices, items | |
Axonaut † | FR | 9 | Companies, invoices, quotations, expenses, products, projects |
† Built from the vendor's published API documentation and not yet exercised against a live tenant. If you run one of these, a report or a fix is very welcome.
Repositories: erp-mcp-server · weclapp-mcp-server · odoo-mcp-server · sap-mcp-server · sap-business-one-mcp-server · xentral-mcp-server
Your ERP isn't listed, or it's a custom or on-prem build? Connect it through its REST API, SOAP services or straight to its SQL database, read-only. That is how KOCH Freiburg runs its ERP in production.
E-commerce & marketplace connectors
Shops and marketplaces, from Amazon and eBay to the DACH marketplaces. Each name links to its setup guide.
System | Market | Tools | What the AI can do |
Global | 15 | Orders, catalog, FBA inventory, offers, fees, financial events, reports | |
Global | 49 | Products, variations, stock, orders, refunds, customers, reports | |
DACH | 6 | Storefront catalog via the Store API: products, categories, cross-sells | |
Global | 12 | Products, stock, orders, customers | |
Global | 14 | Products, variants, inventory, orders, customers | |
Global | 10 | Inventory, offers, orders, disputes, price updates | |
Global | 9 | Listings, receipts (orders), reviews | |
Global | 10 | Products, categories, orders, customers | |
DE | 8 | Orders and units, shipments, tickets, storefronts | |
DE | 8 | Orders, products, returns, stock and price updates | |
EU | 7 | Orders, shipments, returns, stock, prices | |
DACH | 8 | Orders, products, customers, shipping providers | |
LATAM | 4 | Item search, seller orders |
† Built from the vendor's published API documentation and not yet exercised against a live seller account.
Repositories: ecommerce-mcp-server · amazon-seller-mcp-server · billbee-mcp-server · magento-mcp-server · woocommerce-mcp-server · shopware-mcp-server · kaufland-mcp-server · otto-market-mcp-server
What it connects, governs and learns
Connect
5 connector types — REST, SOAP, GraphQL, Database, MCP-to-MCP bridge. Seven database engines: PostgreSQL, MySQL, MariaDB, MSSQL, Oracle, MongoDB, SQLite.
Import from what you already have — OpenAPI/Swagger, Postman, cURL, WSDL, GraphQL introspection, or tool discovery straight from a running MCP server.
The adapter catalog — see what ships.
Visual tool editor — map parameters to path, query, body and headers; rename and describe tools so the AI reads them the way you meant.
Dynamic MCP server — tools register at runtime, no restart. Per-connector
{{VAR}}interpolation, hidden from the AI.
Govern
Response shaping — declare per tool exactly which fields reach the model, with a live before/after preview.
Read-only where it matters. Every tool carries MCP annotations (
readOnlyHint,destructiveHint), derived from the operation and overridable per tool, so a client can show the difference between reading an invoice and issuing a credit note. Role-based tool whitelisting lets you publish an MCP server that can only read — which is how most people should start with an ERP.Every auth scheme you will meet — OAuth2 (PKCE and Client Credentials), Bearer, API Key, Basic, HMAC request signing, LOGIN_TOKEN and OAuth 1.0a.
Audit logging — every tool call recorded with input, output, duration and status, in your own database.
SSO and SCIM — Entra ID, Google, Okta, Auth0, generic OIDC. Roles sync from your directory groups on every sign-in; disable someone in the directory and their workspace access and MCP API keys die with it (self-hosted only).
Learn
Knowledge Graph — a per-workspace, PII-safe map of how your connectors' data relates, served back to the agent as an MCP tool so it chains calls across systems correctly.
AI skills — recurring usage turned into small reusable rules and composed into the server's instructions, so they guide the agent without adding a tool call (optional, opt-in).
Knowledge Graph & AI skills
Forwarding calls leaves the hard part to the agent: knowing which tool to call next, and what your business actually means by "open order" or "active customer". AnythingMCP learns both — how the data in your connectors relates, and how your team really uses the tools — then feeds that back to the AI client as context rather than as extra tool calls.
Knowledge Graph — a per-workspace map of entities (customers, orders, products…) and their relationships. It builds itself from tool names, parameters and the input/output of real calls; an optional AI pass infers the cross-connector links heuristics miss. It stays PII-safe: it stores entity/field names and relationship metadata, never the values.
Build it visually — a graph editor lets you create, edit and delete entities and connections by hand, add descriptions, and curate what the AI proposed.
Served over MCP — each server exposes a
kg_how_to_obtaintool, so the customer's agent can ask "how do I get from a Shopware order to a DHL tracking number?" and receive chaining hints across connectors.AI skills, written from real usage — with intent capture on, each tool call can record why it was made. An AI pass turns recurring patterns into small reusable rules (e.g. "today's revenue includes order statuses 2, 3 and 4"). You Apply, Edit or Dismiss each one, or let auto-apply take the high-confidence ones unattended. Applied skills are composed into the MCP server's instructions at serve time, so they guide the agent without adding a single tool call. The knowledge your team builds up by using the system stops living in someone's head.
The AI passes are off by default — opt in with a global env flag and a per-workspace switch, using OpenAI, OpenRouter or Anthropic. The graph, manual editing and the MCP tool work with no LLM key at all.
➡️ Knowledge Graph & AI skills guide →
Control what the model sees
Every tool can declare exactly which fields leave your infrastructure. The mapping is attached per tool and applied on the way out, so the AI client — and the third-party model behind it — only ever receives the shape you approved.
Drop what should never travel. List the paths to remove and they are stripped before the response reaches the agent: a customer's IBAN, an employee's salary, an access token an API hands back alongside the data.
Or declare the whole output. A
selecttemplate names the fields to keep and what to call them; a JMESPath expression covers the reshaping a template can't express. Where an agent is better served by a stable shape, swap the value for a placeholder ("iban": "= [redacted]") instead of removing the field.See it before you save it. The editor runs the mapping against a real response and shows the before/after side by side, with the size difference. A shipped adapter measures 12,172 B → 1,072 B (−91%) on a four-train result.
It fails open by default, and this says so. If a mapping breaks at runtime, the raw response is returned and a warning is logged, so one bad expression cannot take a working tool offline. That default is wrong for fields that must never travel: set
"fallbackToRaw": falseon those tools and a broken mapping fails the call instead of leaking through it.
Two payoffs at once: sensitive fields never reach the model, and every field you drop is a field you don't pay for in the context window.
{
"transform": {
"mode": "select",
"fallbackToRaw": false,
"exclude": ["customer.iban", "customer.taxId"],
"select": { "order": "$.id", "total": "$.amounts.gross", "status": "$.state" }
}
}The audit log still records the full upstream response inside your own database. Shaping what the agent sees never costs you the evidence of what the API actually returned.
➡️ Response mapping reference →
Build custom Claude connectors — no code
Claude supports custom connectors: remote MCP servers you add once in Customize → Connectors, and that work across Claude.ai, Claude Desktop and Claude Code. AnythingMCP creates that connector from any API you already have — without writing an MCP server:
Import your API spec, or pick a pre-built adapter
Adjust tool names, descriptions and parameters in the visual editor — what the AI sees is up to you
Add your MCP server's URL to Claude as a custom connector (OAuth 2.0 supported out of the box)
Your credentials stay on your infrastructure, every tool call lands in the audit log, and role-based access controls which users see which tools. Step-by-step guide →
Turn your API into a ChatGPT app
Apps in ChatGPT are built on MCP, and AnythingMCP gives you that MCP backend without writing one. Point it at your REST, SOAP, GraphQL or database endpoint and you get a ChatGPT-ready connector: add it in ChatGPT's settings (or use it as the tool layer of an Apps SDK app) and ChatGPT can read and act on your business data.
The same connector works simultaneously in Claude, ChatGPT, Gemini, Copilot and Cursor — build once, connect everywhere. ChatGPT setup guide →
Why AnythingMCP
AI clients speak MCP, but your systems speak REST, SOAP, GraphQL and SQL. Writing and maintaining a bespoke MCP server per system — with auth, audit and access control — takes weeks each. AnythingMCP is the no-code layer in between:
Problem | Solution |
You have REST APIs but AI clients speak MCP | REST → MCP conversion with OpenAPI / Swagger import |
You have legacy SOAP/WSDL services | SOAP → MCP bridge with automatic WSDL parsing |
You need to query databases from AI agents | DB → MCP with auto-generated query tools (7 engines) |
You want one endpoint for all your APIs | MCP middleware that aggregates multiple connectors |
You need an MCP server for SAP Business One / Odoo / Shopware / … | The adapter catalog — install and credential it in a minute |
You can't ship credentials to a third party | Runs on your infrastructure — credentials AES-256-GCM at rest |
You need auth, audit logs and RBAC | Built-in OAuth2, audit log and role-based access — no DIY |
A third-party model would see every field your API returns | Per-tool response mapping — drop or reshape fields before they leave your network |
Your agent calls tools in the wrong order, or misses how two systems connect | Knowledge Graph & AI skills — chaining hints and learned business rules, served as context |
What people actually build with it
Guides | |
Talk to the ERP from Claude | SAP Business One · Odoo · weclapp · Xentral |
Check orders, stock and fees across shops and marketplaces | |
Track parcels | |
Validate an invoice before paying it | |
Let agents read a production database, read-only | |
Bridge a SOAP service from 2009 to a 2026 model | |
Ask about trains, live delays and routes |
The adapter catalog
259 adapters, exposing 2,400+ tools. 21 need no API key; the rest ask for your credentials at import and the tools are available immediately. Every one has a setup guide on anythingmcp.com/guides, in seven languages.
Category | Examples |
📦 Logistics & shipping | Deutsche Bahn, DHL, DPD, GLS, Shipcloud, Sendcloud |
💼 ERP, accounting & invoicing | SAP Business One, Odoo, weclapp, Xentral and 12 more ERPs, Lexware Office, sevDesk, Exact Online, bexio |
🛍️ E-commerce | Amazon Seller, WooCommerce, Shopware 6, Kaufland, OTTO and 8 more, Oxomi |
👥 HR & field service | Personio, HRWorks, Kenjo, MFR Mobile Field Report |
🏛️ Government & public data | VIES VAT, Handelsregister, UK Companies House 🇬🇧, DESTATIS, Bundesbank, OpenPLZ, NINA |
🏦 Banking & payments | Revolut Business, Wise 🇬🇧, PAYONE, Razorpay 🇮🇳, Paystack 🇳🇬 |
💬 Messaging & communication | WhatsApp, LINE 🇯🇵, TeamViewer |
🎾 Sports & Web3 | Playtomic, Sorare |
🏗️ Construction & mapping | PlanRadar, HERE Geocoding |
An adapter is a single JSON file. That is why the catalog is this size, and why adding one is a reasonable first contribution. Missing yours? Request it — we prioritise by 👍 — or build it.
Guides, client setup & FAQ
➡️ docs/guides.md — Claude / ChatGPT / Gemini / Copilot / Cursor setup · REST / SOAP / GraphQL / Database / MCP-bridge connector guides · API reference & deployment docs · FAQ.
Looking for a specific service? Every adapter has a step-by-step guide at anythingmcp.com/guides.
How AnythingMCP compares
AnythingMCP is an MCP gateway that starts one step earlier: it creates the MCP servers from the APIs, ERPs and databases you already run, then serves, scopes and audits them behind one endpoint. The other MCP gateways federate and secure MCP servers you already have, but most companies have none yet — they have a REST API, a SOAP service from 2009 and a database nobody wants to expose. Every project below solves a real problem; they just don't solve the same one.
What it is | Choose it instead if… | |
ContextForge (IBM) | Federation and a registry in front of MCP servers you already have | Your tools are already MCP servers and what you need is federation, virtual servers and a registry |
Runs catalog MCP servers as containers behind one endpoint, with secret handling | You want vendor-published MCP servers sandboxed in Docker and the published catalog covers you | |
Aggregates MCP servers into namespaced endpoints with a middleware layer | You mainly need to group and re-scope existing MCP servers per client | |
A hosted catalog of managed integrations with auth handled for you | A fixed managed catalog is enough and you never need to add your own SOAP service, in-house API or database | |
AnythingMCP | Turns the APIs, SOAP services and databases you already run into MCP tools | Your systems are not MCP servers yet, and you want the choice of holding the credentials yourself |
Side-by-side pages with the full feature tables: anythingmcp.com/vs.
FAQ
How do I connect my ERP (SAP Business One, Odoo, Xentral…) to Claude or ChatGPT? Install the ERP's adapter from the catalog, enter the API credentials, and add your MCP server URL to Claude as a custom connector or to ChatGPT as an app. If your ERP has no adapter, connect its REST or SOAP API or its SQL database directly. Start with a role that can only read.
How do I turn an OpenAPI spec into an MCP server?
Create a REST connector and import the spec by URL or by pasting it; every operation becomes an MCP tool on your server's /mcp endpoint, with no code. How it works.
Can I connect a SOAP/WSDL service to Claude? Yes. AnythingMCP parses the WSDL, turns each operation into a tool and builds the SOAP envelope on every call, WCF services included. It authenticates with HTTP Basic, Bearer or an API-key header; WS-Security headers are not implemented yet. SOAP connector docs.
Can Claude query my SQL Server, Oracle or PostgreSQL database safely?
Database connectors are read-only by default: AnythingMCP only runs a single SELECT (or WITH … SELECT) and blocks writes and stacked statements. On top of that, use a database user with SELECT rights only, prefer static queries where the model supplies just the parameters, and whitelist the tools per role. Response mapping drops the columns that must not reach the model, and every query lands in the audit log in your own database.
How do I connect Shopware, WooCommerce or Amazon Seller Central to Claude? Install the e-commerce adapter for your shop or marketplace and authorise it. WooCommerce comes with 49 tools, Amazon Seller Central uses the official Selling Partner API, and the Shopware 6 adapter reads the storefront catalog through the Store API.
Is AnythingMCP an MCP gateway? Is it self-hosted and free? Yes on all three: one MCP endpoint in front of every connector, with OAuth2, RBAC, SSO and audit. It runs on your own servers under AGPL-3.0, commercial use included; AnythingMCP Cloud is the optional hosted version.
How is it different from Composio? Composio is a hosted catalog of managed integrations. AnythingMCP also turns your own in-house APIs, SOAP services and databases into tools, and can keep every credential on your infrastructure. Full comparison.
Community & support
💬 Questions & discussions — GitHub Discussions — vote on the next adapter, share what you've built
🐛 Bugs / 💡 features — Issues · 🆘 SUPPORT.md
👥 Adopters — ADOPTERS.md — who runs AnythingMCP in production, and how to add yourself
🔐 Security — please do not open a public issue; follow SECURITY.md
🏢 Built by helpcode.ai in Freiburg, Germany. AI-assisted development, human-reviewed — AUTHORS.md says which parts and how.
Contributing
Read the Contributing guide before opening a PR. The easiest useful contribution is an adapter: one JSON file, and there is a walkthrough issue for it.
License
Open source under the GNU Affero General Public License v3 (AGPL-3.0-only). Commercial use inside your own company is included and always was; the copyleft obligation only starts if you modify AnythingMCP and offer the modified version to others over a network. Cloud-operator code under ee/ is separately licensed and is not required for self-hosting — see the License FAQ.
Available Tools
4 toolsanythingmcp_connect_clientARead-onlyIdempotent
Read-only, no side effects. Returns plain-text setup instructions for connecting ONE AI client to an AnythingMCP server; pass the required client. Use this once you already have an AnythingMCP instance running; to install one first, use anythingmcp_get_started.
| Name | Required | Description | Default |
|---|---|---|---|
| client | Yes | Which AI client to get connection instructions for. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, and the description reinforces 'Read-only, no side effects.' It adds value by specifying the output type ('plain-text setup instructions'), but does not elaborate further on behaviors like rate limits or auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, minimal waste, front-loaded with key info (read-only, no side effects, plain-text instructions). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one enum parameter, the description covers purpose, usage context, and output format. No output schema is needed as the result is plain text. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enum and description for the sole parameter. The description adds no additional semantics beyond what the schema already provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns 'plain-text setup instructions for connecting ONE AI client to an AnythingMCP server; pass the required `client`.' This is specific, uses a verb+resource structure, and differentiates from siblings like anythingmcp_get_started.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use this once you already have an AnythingMCP instance running; to install one first, use anythingmcp_get_started.' This provides clear context and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
anythingmcp_get_startedARead-onlyIdempotent
Read-only, no side effects. Returns copy-pasteable plain-text steps to install and run your own AnythingMCP gateway in ~60 seconds (self-host with Docker, or the managed cloud). Use this when you want to DEPLOY AnythingMCP; to connect an already-running instance to an AI client, use anythingmcp_connect_client instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description starts with 'Read-only, no side effects', confirming annotations. Adds context about returning plain-text steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key behaviors, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is complete, covering purpose, side effects, and use case differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline 4. Description doesn't need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: returns copy-pasteable steps to install/run AnythingMCP. Distinguishes from sibling 'anythingmcp_connect_client'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (deploy AnythingMCP) and when not (for connecting, use alternative). Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
anythingmcp_list_connectorsARead-onlyIdempotent
Read-only, no side effects. Returns a plain-text catalog of AnythingMCP's 258 pre-built connectors grouped by category (logistics, ERP, e-commerce, HR, public data, banking, messaging, sports), plus the 5 connector types you can build with no code (REST, SOAP/WSDL, GraphQL, Database, MCP-bridge), with a link to the full list. Use this to discover available integrations before connecting a client.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds that it returns plain-text and is read-only, which reinforces the annotations. It adds no further behavioral detail like response size or pagination, but given the annotations cover the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense paragraph, front-loaded with the key behavioral trait ('Read-only, no side effects'). It efficiently conveys the catalog details without excessive fluff, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and the annotations cover safety, the description is quite complete. It specifies the return format (plain-text), the content (count and types), and categorization. Minor gaps like whether the list is exhaustive or includes descriptions of each connector are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameters. The baseline for 0 params is 4, and the description provides rich context about the content of the catalog, which enhances the user's understanding of what to expect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connectors, specifies the 258 pre-built types and the 5 buildable types, and groups them by category. It also distinguishes it from siblings like anythingmcp_connect_client by focusing on discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('before connecting a client'), but does not provide explicit when-not-to-use guidance or mention alternative tools. However, the context is clear enough for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
anythingmcp_overviewARead-onlyIdempotent
Read-only, no side effects. Returns a concise plain-text overview of AnythingMCP (a self-hosted, no-code MCP gateway) with links to the website, GitHub repo and cloud. Call this FIRST to understand the product; then use anythingmcp_get_started to install it, anythingmcp_connect_client to wire up an AI client, or anythingmcp_list_connectors to browse integrations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description redundantly states 'Read-only, no side effects,' which adds no new behavioral context beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear front-loading: 'Read-only, no side effects. Returns a concise plain-text overview...' No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a parameterless, read-only tool with good annotations. Description covers what it does, why to call it, and how to proceed with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so baseline is 4. Description does not need to add parameter info and doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool returns a concise plain-text overview of AnythingMCP with links, and distinguishes it from siblings by specifying it should be called first to understand the product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this FIRST' and then lists when to use three specific sibling tools (anythingmcp_get_started, anythingmcp_connect_client, anythingmcp_list_connectors), providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.1- Changed
anythingmcp_connect_client1 field changed- changed
Input schema / properties / client / descriptionPrevious value: -"Which AI client to connect."New value: +"Which AI client to get connection instructions for."
4 tool updates
v0.1.0- First observed
anythingmcp_connect_client - First observed
anythingmcp_get_started - First observed
anythingmcp_list_connectors - First observed
anythingmcp_overview
TDQS
Scored across 4 tools
Each tool covers a distinct stage: overview, connect, deployment, and connector catalog. The descriptions explicitly cross-reference one another and clarify when to use each, leaving little room for selection error.
All tools share the anythingmcp_ prefix and use snake_case, but naming style is slightly uneven: list_connectors and connect_client use verb_noun, get_started uses verb_adjective, and overview is a bare noun. This is a minor deviation from an otherwise predictable pattern.
Four tools is well-scoped for an informational server about a product. Each tool covers a necessary user journey without redundancy or bloat.
The tool surface covers the main user flow: understand the product, install it, connect a client, and browse connectors. Minor gaps exist, such as no troubleshooting or pricing tool, but they are not critical to the server's stated purpose.
Maintenance
Related MCP Connectors
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Unified gateway exposing 150+ tools across all NexGenData MCP servers via one endpoint.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Related MCP Servers
- FlicenseCqualityDmaintenanceA powerful gateway for the Model Context Protocol (MCP) that unifies AI toolchains by federating multiple MCP servers, wrapping REST APIs as MCP tools, and supporting multiple transport methods with an admin dashboard.1-
- AlicenseNot gradedqualityBmaintenanceMCPJungle is a self-hosted MCP Registry and Gateway suitable for both local and enterprise deployments. It provides a single URL for your MCP clients to access servers and a central platform for you to track your MCPs and client-server interactions.1,287Mozilla Public 2.0
- AlicenseAqualityCmaintenanceProvides per-Subagent MCP controls to any coding agent or client across all your MCPs and prevents context window waste. Loads only 3 tools instead of all your MCP Server's tool definitions. Agents discover tools on-demand, only when needed and only the servers and tools they are allowed.446 PyPI41MIT

mcpgateofficial
FlicenseNot gradedqualityCmaintenanceSelf-hosted MCP gateway that connects Claude, ChatGPT, and other AI agents to 20+ enterprise tools (GitLab, Jira, Notion, Google Workspace, Slack, Grafana, …) with OAuth, audit logs, and zero data leaving your infrastructure-