Read-only MCP server that provides guidance on AnythingMCP and its ecosystem; it cannot modify anything.
Get a concise overview of AnythingMCP, including links to its website, GitHub repo, and cloud.
Retrieve copy-pasteable steps to install and run your own AnythingMCP gateway in about 60 seconds via Docker or managed cloud.
Get setup instructions for connecting one AI client to an AnythingMCP server: Claude, ChatGPT, Meta Muse, Gemini, Copilot, or Cursor.
Browse a catalog of 490 pre-built connectors grouped by category, plus 5 no-code connector types: REST, SOAP/WSDL, GraphQL, Database, and MCP-bridge.
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.
529 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 | 24 | Business partners, items, sales documents, A/P invoices, payments, journal entries, chart of accounts, bank reconciliations; 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 | 10 | Items, stock per warehouse, customers, sales orders, shipments |
Xentral † | DE | 30 | Products, stock per warehouse and bin, customers, suppliers, sales orders, delivery notes, invoices with payment status, credit notes, purchase orders; create order drafts |
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 | 12 | 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 · 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 | 13 | Products, stock, orders, customers | |
Global | 14 | Products, variants, inventory, orders, customers | |
Global | 10 | Inventory, offers, orders, disputes, price updates | |
Global | 22 | Listings, receipts (orders), reviews | |
Global | 10 | Products, categories, orders, customers | |
DE | 7 | Orders and units, tickets, storefronts, warehouses | |
DE | 8 | Orders, products, returns, stock and price updates | |
EU | 5 | 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 · billbee-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. On AnythingMCP Cloud you can also add it in one click from the Claude Directory. Claude setup
ChatGPT. Apps in ChatGPT are built on MCP. Add the server under Plugins in ChatGPT (+ → Add custom MCP server), or use it as the tool layer of an Apps SDK app. ChatGPT setup
Meta Muse. In Muse, open Settings → Connectors → Add custom connector, paste the server URL and sign in to AnythingMCP. Muse 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, an API-key header or a WS-Security UsernameToken; signed WS-Security messages are not supported 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 declare readOnlyHint, idempotentHint and openWorldHint=false, so "Read-only, no side effects" is largely redundant. However, the description adds the return format (plain-text setup instructions) and the one-client-per-call scope, which is genuinely useful since there is no output schema.
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 tight sentences with zero waste; the behavioral/safety claim and the resource are front-loaded, followed by the routing rule to the sibling tool.
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 single-parameter, read-only tool with no output schema, the description covers scope, safety, output form and the sibling prerequisite path. Nothing an agent needs to invoke it correctly 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?
Schema description coverage is 100% and the single enum parameter is already documented in-schema with its allowed values. The description only restates that `client` is required and singular, adding no syntax or format detail beyond the schema.
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?
States a specific verb+resource (returns plain-text setup instructions) with an explicit scope of ONE AI client, and the required `client` argument. It clearly distinguishes itself from the sibling anythingmcp_get_started, which handles installation rather than connection.
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?
Gives an explicit precondition ("once you already have an AnythingMCP instance running") and names the alternative for the other case ("to install one first, use anythingmcp_get_started"). The agent has no inference left to make about when this tool applies.
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 543 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=false, so 'Read-only, no side effects' mostly restates them. The description does add value beyond the structured data by disclosing the return shape — a plain-text catalog grouped by category with a link to the full list — which tells the agent what to expect from the response.
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 safety profile and the core action statement. The enumerated category list is somewhat bulky but does set expectations about catalog breadth, so it largely earns its place.
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?
There is no output schema, so the description must carry return-value information, and it does: plain-text format, grouping by category, and a pointer to the full list. What remains unsaid is whether the catalog is paginated or truncated, a minor gap for a zero-parameter read.
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 there is nothing to disambiguate and the schema is fully covered. Baseline of 4 applies; no further parameter explanation is possible or needed.
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?
Specific verb + resource ('list connectors') with the exact scope quantified: 543 pre-built connectors grouped by category plus 5 no-code connector types. An agent can immediately distinguish this discovery tool from anythingmcp_connect_client, which it names as the downstream action.
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 final sentence gives explicit guidance: 'Use this to discover available integrations before connecting a client,' which establishes the correct ordering relative to connect_client. It stops short of naming alternatives or stating when NOT to use it (e.g., when the connector is already known).
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.32.1anythingmcp_connect_client1 field changedInput schema / properties / client / enumPrevious value: -[
- "claude",
- "chatgpt",
- "gemini",
- "copilot",
- "cursor"
-]New value: +[
+ "claude",
+ "chatgpt",
+ "muse",
+ "gemini",
+ "copilot",
+ "cursor"
+]Scored across 4 tools
Each tool has a clearly distinct purpose: overview, install/run, connect a client, and browse connectors. Descriptions explicitly cross-reference adjacent tools, making misselection unlikely.
All four tools follow a consistent prefix plus snake_case verb_noun pattern: anythingmcp_overview, anythingmcp_get_started, anythingmcp_connect_client, anythingmcp_list_connectors.
Four tools are well-scoped for an onboarding/discovery server. Each tool covers a distinct stage of the user journey without unnecessary surface area.
The surface covers the core journey from product overview to installation, client connection, and connector discovery. Minor gaps include no connector search/filter or detailed connector lookup, but the stated purpose is largely met.
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.
Managed MCP gateway with OAuth, per-agent permissions, shared accounts and activity logs.
One MCP endpoint for your company's tools, with per-person sign-in, policy and audit.
