anythingmcp
This server is a read-only, informational assistant for AnythingMCP: it helps you learn about the product, install it, connect AI clients, and discover connectors — it performs no actual integrations or side effects.
Overview — Get a concise plain-text introduction to AnythingMCP with links to the website, GitHub, and cloud.
Get started — Receive copy-pasteable steps to self-host AnythingMCP with Docker or use the managed cloud.
Connect an AI client — Get setup instructions for connecting one client (Claude, ChatGPT, Gemini, Copilot, or Cursor) to an existing AnythingMCP instance.
List connectors — Browse the 175+ pre-built connectors by category and the 5 no-code connector types (REST, SOAP/WSDL, GraphQL, Database, MCP-bridge) with a link to the full catalog.
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.
AnythingMCP is a self-hosted, open-source smart, AI-empowered MCP gateway and MCP server that turns the systems you already run into Model Context Protocol tools — REST and SOAP APIs, GraphQL, SQL & NoSQL databases, and even other MCP servers. Import a spec or point it at a database, and expose it as a custom connector to Claude, ChatGPT, Gemini, Copilot, Cursor and any MCP-compatible client. No SDK, no code changes — point, configure, connect.
It ships with 188 ready-to-use adapters — including Deutsche Bahn, weclapp ERP, Etsy, Shopware, DHL and Sendcloud — so the most common integrations work in one click, while the visual editor and import tools (OpenAPI/Swagger, Postman, cURL, WSDL, GraphQL) let you wrap any other API or database in minutes.
What makes it smart, not just a pipe: AnythingMCP builds a per-workspace Knowledge Graph of how your connectors' data relates, serves it back to the agent over MCP so it chains tools correctly across systems, and turns how your tools are actually used into reusable AI skills. A plain gateway forwards calls; AnythingMCP gives your agents the context to use them well. (All AI features are optional and opt-in — the gateway works fully without them.)
And because every call runs through your own infrastructure, you decide what leaves it: per-tool response mapping declares which fields ever reach the model, so PII and secrets can be dropped before the answer goes out, while the audit log keeps the full upstream response on your side.
https://github.com/user-attachments/assets/2ae92f90-7012-4c00-8836-bae5a6422ca6
Get started in 60 seconds
Requires Docker 24+,
bash,openssl. On macOS, start Docker Desktop first.
git clone https://github.com/HelpCode-ai/anythingmcp.git
cd anythingmcp && ./setup.sh
# When setup finishes, open http://localhost:3000 and register
# the first user — they automatically become the admin.The interactive setup handles everything: deployment mode, domain & HTTPS (automatic Let's Encrypt via Caddy), secrets, MCP auth mode, optional SMTP/Redis.
⚠️ Register immediately after setup. The first account to register becomes Admin. If your instance is reachable from the internet during setup, configure firewall rules or bind the UI to
127.0.0.1until you've created the admin account.
Service | Default URL |
Web UI |
|
MCP endpoint |
|
Swagger docs |
|
Or one-click deploy:
Prefer manual setup? Copy
.env.exampleto.envand rundocker compose up -d— see the Deployment Guide.
Related MCP server: MCPJungle mcp gateway
Key features
5 connector types — REST, SOAP, GraphQL, Database (PostgreSQL, MySQL, MariaDB, MSSQL, Oracle, MongoDB, SQLite), MCP-to-MCP bridge
6 import formats + live discovery — OpenAPI/Swagger, Postman, cURL, WSDL, GraphQL introspection, custom JSON, plus tool discovery straight from a running MCP server
188 pre-built adapters — logistics, ERP, HR, e-commerce, payments, public data — see catalog
Visual tool editor — map parameters to path, query, body, headers; rename and describe tools for the AI
Dynamic MCP server — tools registered at runtime, no restart
Knowledge Graph & AI skills — a per-workspace, PII-safe map of how your connectors' data relates, served to the agent via an MCP tool, plus reusable AI skills composed into the server's instructions (optional, opt-in)
Response shaping & data governance — declare per tool exactly which fields reach the model; drop PII, secrets and noise before they leave your network, with a live before/after preview
Full auth — OAuth2 (PKCE + Client Credentials), Bearer, API Key, Basic, WS-Security, client certificates, LOGIN_TOKEN and OAuth 1.0a handshakes
Audit logging — every tool call logged with input, output, duration, status
Roles & access control — tool-level whitelisting per custom role, per-user MCP API keys
Environment variables — per-connector
{{VAR}}interpolation, hidden from the AIDocker ready —
docker compose upand you're running
Knowledge Graph & AI skills
A gateway that only forwards 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. Zoom/fit controls, connectivity-based layout and hover focus make a large graph navigable.
Served over MCP — each server exposes a
kg_how_to_obtaintool so the customer's agent can ask "how do I get this?" 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"), scoped to a connector or a whole server. You Apply / Edit / Dismiss each one, or let auto-apply take the high-confidence ones (≥ 0.90) 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, and editing one takes effect on the next request. Consolidate with AI merges overlapping rules back into a tight set as they accumulate. The knowledge your team builds up by using the system stops living in someone's head.
The AI passes (graph enrichment, skill generation, scheduled extension) work with OpenAI, OpenRouter or Anthropic and are off by default — opt-in with a global env flag and a per-workspace switch. 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.
Fails safe. A broken mapping returns the raw response and logs a warning rather than breaking a working tool — unless you explicitly opt out.
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",
"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 Settings → 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 (OpenAPI/Swagger, Postman, cURL, WSDL, GraphQL introspection) 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 the gateway URL to Claude as a custom connector (OAuth 2.0 supported out of the box)
Your credentials stay on your infrastructure (AES-256-GCM at rest), 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 — what OpenAI renamed connectors to in December 2025 — 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 MCP gateway for all your APIs | MCP middleware that aggregates multiple connectors |
You need an MCP server for Deutsche Bahn / DHL / weclapp / … | 188 pre-built adapters — install in one click |
You can't ship credentials to a SaaS gateway | 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 |
Typical use cases — search train schedules and live delays with Deutsche Bahn · talk to your ERP from Claude (weclapp, Xentral) · track parcels with AI (DHL, GLS) · validate invoices (VIES VAT, Handelsregister) · let agents query production databases safely · bridge legacy SOAP to modern AI · import a Postman collection and get MCP tools instantly.
Pre-configured MCP connectors
AnythingMCP ships with 188 ready-to-use adapters — provide your API credentials at import time and the tools become available immediately. Every adapter 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 | weclapp, Xentral, Scopevisio, Billomat, FastBill |
🛍️ E-commerce | Etsy, Shopware 6, WooCommerce, Mercado Libre 🌎, ImmobilienScout24, 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 | N26, Wise 🇬🇧, PAYONE, Razorpay 🇮🇳, Paystack 🇳🇬 |
💬 Messaging & communication | WhatsApp, LINE 🇯🇵, TeamViewer |
🎾 Sports & Web3 | Playtomic, Sorare |
🏗️ Construction & mapping | PlanRadar, HERE Geocoding |
Guides, client setup & FAQ
Connecting an AI client, the connector types you can build, full documentation and the FAQ now live in one place:
➡️ 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.
Community & support
💬 Questions & discussions — GitHub Discussions — vote on the next adapter, share what you've built
🐛 Bugs / 💡 features — Issues · 🆘 SUPPORT.md
🏢 Built by helpcode.ai in Freiburg, Germany — AnythingMCP was extracted from a production system connecting AI agents to 15+ legacy systems (ERP, CRM, SOAP, on-prem databases) in a German industrial group, and open-sourced because the catalog grows faster as a community. AI-assisted development, human-reviewed: see AUTHORS.md.
⭐ Like what you see? Star this repo — every star helps another developer discover AnythingMCP.
Contributing
We welcome contributions! Please read our Contributing guide before submitting a PR. For security issues, see SECURITY.md.
License
AnythingMCP is open source, licensed under the GNU Affero General Public License v3 (AGPL-3.0-only). Cloud-operator code under ee/ directories is separately licensed and is not required for self-hosting — see the License FAQ.
Available Tools
4 toolsanythingmcp_connect_clientARead-onlyIdempotentInspect
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-onlyIdempotentInspect
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-onlyIdempotentInspect
Read-only, no side effects. Returns a plain-text catalog of AnythingMCP's 175+ 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?
The description adds value beyond annotations by detailing the output format (plain-text catalog), specific contents (categories, connector types, link), and reinforces the read-only nature. With annotations already providing readOnlyHint and idempotentHint, the description enriches behavioral understanding.
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 three sentences, front-loaded with key behavioral info, and every sentence provides useful information without redundancy. It is efficiently structured.
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 parameterless tool with no output schema, the description covers the return value (plain-text catalog with categories and link) comprehensively. It is complete for the tool's purpose of discovery.
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 input schema has no parameters (100% coverage, 0 params). The description doesn't need to add parameter information since there are none. Baseline for 0 parameters is 4.
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 'Returns a plain-text catalog of AnythingMCP's 175+ pre-built connectors grouped by category... plus the 5 connector types you can build with no code'. It identifies the specific verb and resource, and the content clearly distinguishes this from sibling tools like 'connect_client' or '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?
The tool explicitly says 'Use this to discover available integrations before connecting a client', providing clear context for when to use it. While it doesn't explicitly state when not to use it or mention alternatives, the guidance is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
anythingmcp_overviewARead-onlyIdempotentInspect
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. Dates show when Glama detected each change.
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
Each tool has a clearly distinct purpose: overview introduces the product, get_started guides installation, connect_client explains client integration, and list_connectors catalogs integrations. No overlap or ambiguity.
All tools follow a consistent 'anythingmcp_verb_noun' pattern (connect_client, get_started, list_connectors, overview). The naming is uniform and predictable.
With 4 tools, the set is tightly scoped to the server's purpose of onboarding and exploring AnythingMCP. Each tool earns its place, and the count is appropriate for the domain.
The tools cover the core user journey: overview, installation, client connection, and integration discovery. Minor gaps exist (e.g., no tool for advanced configuration or troubleshooting), but the essential needs are met.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
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,237Mozilla 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.441MIT

mcpgateofficial
FlicenseNot gradedqualityAmaintenanceSelf-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-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HelpCode-ai/anythingmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server