This server is a read-only documentation/help server for AnythingMCP — it explains the product, tells you how to deploy it, how to wire it into an AI client, and which connectors exist; it does not itself connect to your systems or run any operations.
anythingmcp_overview — get a concise plain-text overview of AnythingMCP (self-hosted, no-code MCP gateway) with links to the website, GitHub repo and cloud; intended as the first call.
anythingmcp_get_started — get copy-pasteable steps to install and run your own gateway in ~60 seconds (self-hosted via Docker, or the managed cloud).
anythingmcp_connect_client — get setup instructions for connecting one AI client to an existing AnythingMCP instance; requires a client argument, one of claude, chatgpt, gemini, copilot, cursor.
anythingmcp_list_connectors — browse a catalog of pre-built connectors grouped by category (logistics, ERP, e-commerce, HR, public data, banking, messaging, sports), plus the no-code connector types (REST, SOAP/WSDL, GraphQL, Database, MCP-bridge).
Note: every tool is annotated readOnlyHint: true, openWorldHint: false and taskSupport: forbidden, so there are no side effects — you can only read guidance, not configure or call real integrations. The schema advertises 265 connectors while the README says 261, a minor inconsistency in the catalog count.
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.
One question in Claude, answered from Etsy, SAP and a logistics API.
https://github.com/user-attachments/assets/cc8c9ef3-11cf-4eab-aa4d-98472dc554b3
Requires Docker 24+ and openssl; on macOS, start Docker Desktop first. No clone needed:
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. Your MCP endpoint is http://localhost:4000/mcp, the API docs are at http://localhost:4000/api/docs.
Keep the generated
.env.ENCRYPTION_KEYdecrypts the credentials you store. Lose it and every connector has to be re-credentialed.
On amd64 the image pulls in about 30 s and the API is healthy 24 s later. The image is amd64 only for now; the compose file pins the platform, so it also runs on Apple Silicon under emulation.
The quickstart binds to 127.0.0.1 on purpose, because 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, with a 7-day free trial. Start there to try it on your own APIs, 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
Add a connector. Install an adapter from the catalog (a ready JSON definition for SAP, Odoo, DHL and the rest), or point AnythingMCP at your own OpenAPI spec, WSDL, GraphQL endpoint, Postman collection or database. Once configured in your workspace it is a connector, and each of its operations is an MCP tool.
Decide what the model sees. 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.
Hand one URL to your AI client. An 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.
Most companies have no MCP servers yet. They have a REST API, an ERP, a SOAP service from 2009 and a database. Each of them becomes a set of MCP tools:
Source | What you get | Docs |
OpenAPI / Swagger (REST) | Import a spec by URL or paste it; every operation becomes a tool with parameters, auth and endpoint mapping filled in | |
Postman collection, cURL | Folders, auth, body modes and | |
SOAP / WSDL | Each operation becomes a tool; envelopes, parameter order and WCF services are handled for you | |
GraphQL | Introspection turns queries and mutations into tools, or you define the operations yourself | |
OData (SAP Gateway included) | Reads each service's | |
SQL and MongoDB | PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SAP HANA, SQLite and MongoDB: schema, example and query tools, read-only by default | |
Another MCP server | Discover its tools and serve them next to your own, behind the same auth and audit |
Tools register at runtime, without a restart. Per-connector {{VAR}} values are interpolated on the server and never shown to the AI.
261 adapters, exposing 2,400+ tools. Every one has a setup guide on anythingmcp.com/guides, in seven languages.
Category | Examples |
💼 ERP, accounting & invoicing | SAP Business One, SAP S/4HANA, Odoo, weclapp, Xentral, Dynamics NAV, Lexware Office, sevDesk, Exact Online, bexio |
🛍️ E-commerce & marketplaces | Amazon Seller, WooCommerce, Shopware 6, Magento, eBay, Etsy, Kaufland, OTTO, Oxomi |
📦 Logistics & shipping | Deutsche Bahn, DHL, DPD, GLS, Shipcloud, Sendcloud |
👥 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 | WhatsApp, LINE, TeamViewer |
📈 Advertising & analytics | Google Ads, Google Analytics 4, Google Search Console, Matomo |
🧠 AI decision models | Jev by TypeSafe: yes/no, classification and scoring with probabilities, in about 300 ms |
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 | 10 | S/4HANA on-premise and Private Cloud read straight from HANA, with SAP's data dictionary and CDS views as tools; read-only | |
Global | 7 | Gateway OData services with SAP's labels: journal entry items, billing documents, sales orders, business partners, stock, products | |
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-hana-mcp-server · sap-business-one-mcp-server · xentral-mcp-server
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
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. Your ERP isn't listed, or it's a custom build? Connect its REST API, its SOAP services or its SQL database directly, read-only.
Everything runs on your infrastructure, so you decide what leaves it. OAuth2, RBAC, SSO and SCIM are in the self-hosted build, not held back for a paid tier.
Response mapping. Each tool declares exactly which fields reach the model: drop a customer's IBAN or an employee's salary, or name the fields to keep. The editor shows the before/after on a real response; a shipped adapter goes from 12,172 B to 1,072 B (−91%), so you also stop paying for those fields in the context window. A broken mapping returns the raw response by default; set "fallbackToRaw": false on tools whose fields must never travel, and the call fails instead.
Read-only where it matters. Every tool carries MCP annotations (readOnlyHint, destructiveHint), derived from the operation and overridable per tool. Role-based tool whitelisting lets you publish an MCP server that can only read, which is how most people should start with an ERP. Database query tools run a single SELECT and block writes and stacked statements.
Every auth scheme you will meet. OAuth2 (PKCE and Client Credentials), Bearer, API key, Basic, HMAC request signing, LOGIN_TOKEN and OAuth 1.0a. Credentials are encrypted at rest with AES-256-GCM.
Audit log. Every tool call is recorded with input, output, duration and status in your own database, including the full upstream response the model never saw.
SSO and SCIM. Entra ID, Google, Okta, Auth0 or any OIDC provider. Roles sync from your directory groups on every sign-in; disable someone in the directory and their workspace access and MCP API keys go with it.
{
"transform": {
"mode": "select",
"fallbackToRaw": false,
"exclude": ["customer.iban", "customer.taxId"],
"select": { "order": "$.id", "total": "$.amounts.gross", "status": "$.state" }
}
}The same MCP server works in every client that speaks MCP, so you build a connector once:
Claude. Add the server URL as a custom connector under Customize → Connectors; it then works in Claude.ai, Claude Desktop and Claude Code. OAuth 2.0 is supported out of the box. Claude setup
ChatGPT. Apps in ChatGPT are built on MCP. Add the server in ChatGPT's settings, or use it as the tool layer of an Apps SDK app. ChatGPT setup
Copilot, Gemini, Cursor and other MCP clients: client setup guides.
Forwarding calls leaves the hard part to the agent: knowing which tool to call next, and what your business means by "open order". AnythingMCP learns both and hands them back as context, not as extra tool calls.
Knowledge Graph. A per-workspace map of entities (customers, orders, products) and how they relate across connectors, built from tool definitions and real calls, and editable by hand. It stores field names and relationships, never values. Each server exposes it through a kg_how_to_obtain tool, so the agent can ask how to get from a Shopware order to a DHL tracking number.
AI skills. Recurring usage turned into small rules ("today's revenue includes order statuses 2, 3 and 4") that you apply, edit or dismiss, and that are composed into the server's instructions.
The AI passes are off by default and use your own OpenAI, OpenRouter or Anthropic key; the graph, the editor and the MCP tool work without one. Knowledge Graph guide
Most MCP gateways federate and secure MCP servers you already have. AnythingMCP 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. If your tools are already MCP servers and all you need is federation, a pure gateway may be enough. Side-by-side comparisons: anythingmcp.com/vs.
A single MCP endpoint in front of many tools, which handles authentication, access control and audit for all of them. AI clients such as Claude and ChatGPT connect to the gateway instead of to each system. AnythingMCP is a gateway that also generates the tools, from APIs and databases that have no MCP server of their own.
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.
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
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
Query tools are read-only by default. 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 your audit log.
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.
In production at KOCH Freiburg GmbH, where it connects AI assistants to 15+ internal systems: ERP, CRM, SOAP services and on-prem databases. helpcode.ai extracted it from that system and open-sourced it, because an adapter catalog grows faster as a community than as a product.
💬 Questions and ideas: GitHub Discussions. Vote on the next adapter, share what you've built.
👥 Adopters: who runs AnythingMCP in production, and how to add yourself
🔐 Security: please do not open a public issue; follow the security policy
🤖 For AI agents and crawlers: anythingmcp.com/llms.txt
🏢 Built by helpcode.ai in Freiburg, Germany. AI-assisted development, human-reviewed: AUTHORS.md says which parts and how.
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.
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.
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. |
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.
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 | |||
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.
Read-only, no side effects. Returns a plain-text catalog of AnythingMCP's 267 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so "Read-only, no side effects" largely repeats structured data. The description earns credit for the disclosure that does not exist elsewhere: the return is a plain-text catalog with a link to the full list, i.e. the shape and limits of the output.
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 the catalog contents enumerated efficiently. The opening clause is somewhat wasted since it duplicates the readOnlyHint annotation, but the rest of the text is dense and non-repetitive.
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?
With no output schema and no annotations describing the return, the description carries the burden and does so: it states the format (plain text), the grouping (by category), the volume (267 + 5 types) and points to the full list. Nothing an agent needs to call and interpret it is missing.
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 takes zero parameters, so the baseline is 4 and there is no syntax the description could add. The description correctly implies no input is required to obtain the catalog.
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?
Names a specific verb and resource (list connectors) and enumerates exactly what the payload contains: 267 pre-built connectors by category plus 5 no-code connector types. It also implicitly separates itself from anythingmcp_connect_client by framing itself as the discovery step.
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?
"Use this to discover available integrations before connecting a client" gives a clear trigger and positions the tool in sequence relative to connect_client. It stops short of stating when not to use it (e.g. vs. anythingmcp_overview or get_started), so it is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1anythingmcp_connect_client1 field changedInput schema / properties / client / descriptionPrevious value: -"Which AI client to connect."New value: +"Which AI client to get connection instructions for."v0.1.0anythingmcp_connect_clientanythingmcp_get_startedanythingmcp_list_connectorsanythingmcp_overviewScored across 4 tools
Each tool maps to a distinct stage of the AnythingMCP lifecycle (overview → install → connect → browse integrations) and descriptions explicitly cross-reference each other to prevent misselection. There is no functional overlap in content or trigger conditions.
All names share a consistent anythingmcp_ prefix and snake_case formatting, but suffix patterns vary slightly: two verb_noun tools, one verb_past_participle (get_started), and one bare noun (overview). Still predictable overall.
Four tools form a tight, well-scoped informational set for onboarding and integration discovery. Every tool earns its place, with no redundancy or forced minimalism.
Covers product overview, installation, client connection, and connector catalog, but lacks a tool to retrieve details for a specific connector or search/filter the 267 connectors. Minor gap for a read-only info server.
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.
