Repository: https://github.com/comind-pro/comind-mcp
MCP-Gateway – verbindet verschiedene MCP-Server und REST-APIs, ermöglicht das Kuratieren und Kombinieren von Tools, die Organisation in Gruppen (jede = ein separater virtueller MCP-Server mit einem einzigen Endpunkt) und deren Bereitstellung für Agenten. Ein Agent sieht nur die ihm zugewiesene schmale Auswahl an Tools und kann über MCP eigene Cron-Jobs planen.
Selbst gehostet: ein einzelner Node-Dienst + Postgres. Mehrbenutzer-fähig mit Isolation pro Konto.
Source (mcp │ openapi │ http) ──import──▶ Tool (native │ composite, curated)
│
Group = virtual MCP ◀──toolset[]──────────────┘ + built-in self-cron tools
└─▶ /g/:groupId/mcp (Streamable HTTP, single endpoint)
└─▶ Agent (Bearer key) — only granted V-MCPs, schedules itself
Vault (${secret.X}) · Scheduler · CallLog / MetricsVoraussetzungen: Node 20+, pnpm 9 (corepack enable), Docker (lokales Postgres).
make setup # install deps, start Postgres, apply migrations
make dev # Postgres + server :8787 + web :5173Web-UI – http://localhost:5173 (Konto registrieren, dann anmelden)
Gateway + Control-API – http://localhost:8787 (GET /healthz)
Postgres – läuft in Docker (docker compose); die .env des Repos bildet den Host-Port 5434 ab
Siehe make help für alle Ziele. Die zugrundeliegenden pnpm-Skripte (pnpm dev, pnpm dev:server, pnpm dev:web) funktionieren weiterhin, verwalten aber den Postgres-Container nicht.
Der Speicher wird durch das Schema von DATABASE_URL ausgewählt – gleiches Schema, gleiche Migrationen:
| Modus | Verwendung für |
| Externes Postgres | Produktion, Multi-Instanz (horizontale Skalierung). |
| Eingebettetes Postgres (PGlite) | Null-Infrastruktur-Self-Host, einzelner Container, Demos, Glama. |
| Eingebettet, im Arbeitsspeicher | Wegwerf-/CI-Smoke. |
PGlite ist Postgres (WASM), daher läuft alles (jsonb, percentile_cont, Migrationen) unverändert – kein externer DB-Prozess. Persistenz: Das file:-Verzeichnis ist ein echtes Postgres-Datenverzeichnis; binden Sie es als Volume ein (z.B. /data), um Daten über Releases hinweg zu behalten. Migrationen sind additiv und idempotent, daher löscht ein Upgrade niemals vorhandene Daten. Der eingebettete Modus ist Single-Node (keine Multi-Instanz – ein Schreiber).
# zero-infra: no Docker/Postgres needed
DATABASE_URL=file:/data/comind SERVER_ENV=dev pnpm --filter comind-server startRelated MCP server: Figma MCP Server
Quellen → eine Quelle hinzufügen (MCP-Proxy, OpenAPI oder HTTP) → Testen → Tools importieren.
Tools → umbenennen / unnötige ausblenden / ein Composite erstellen (ein Intent-Tool aus mehreren Aufrufen).
Gruppen → eine Gruppe erstellen → das Toolset markieren (Kontrollkästchen) → (optional) einen Zeitplan hinzufügen.
Agenten → einen Agenten in der Gruppe erstellen → einen API-Key (einmalig) + MCP Endpunkt erhalten.
Verbinden Sie einen beliebigen MCP-Client mit http://localhost:8787/g/<groupId>/mcp mit Authorization: Bearer <key>. Der Client sieht nur das Toolset der Gruppe (+ Self-Cron-Tools).
Protokolle → Aufrufe, Metriken, Fehler.
Begriff | Was es ist |
Quelle | Upstream: ein anderer MCP-Server (Proxy), eine REST-API (OpenAPI 3.x → Tools) oder ein HTTP-Dienst mit expliziten Endpunkten |
Tool | Ein einzelner Aufruf. |
Composite | Führt deterministisch mehrere Aufrufe aus und setzt ein einzelnes Ergebnis zusammen (Ausgabevorlage, |
Python-Tool | Ein Python-Programm, das in einer WASM-Sandbox ausgeführt wird – kein Netzwerk, kein Dateisystem. Greift auf andere Tools über |
Gruppe | Ein virtueller MCP-Server: ein kuratiertes Set von Tools, bereitgestellt als einzelner Endpunkt |
Agent | Ein Verbraucher, der über einen API-Key an eine Gruppe gebunden ist. Sieht nur das Toolset der Gruppe |
Self-Cron | MCP-Tools |
Geheimnis | Eine verschlüsselte Anmeldeinformation (AES-256-GCM) oder eine Umgebungsreferenz. Wird zur Laufzeit über |
GET /healthz
# sources
POST/GET /sources GET/PATCH/DELETE /sources/:id
POST /sources/:id/test POST /sources/:id/import
# tools
GET /tools (?sourceId&kind&visible) GET/PATCH/DELETE /tools/:id
# composites
POST/GET /composite-tools GET/DELETE /composite-tools/:id POST /composite-tools/:id/run
# python tools (gated — see "Python tools")
POST /python-tools GET/PATCH/DELETE /python-tools/:id
POST /python-tools/test POST /python-tools/:id/run
GET /features
# groups
POST/GET /groups GET/PATCH/DELETE /groups/:id
GET/PUT /groups/:id/tools
# agents
POST/GET /agents GET/DELETE /agents/:id POST /agents/:id/rotate-key
# schedules
POST/GET /groups/:id/schedules DELETE /schedules/:id
POST /schedules/:id/run GET /schedules/:id/runs
# secrets (metadata only; value/ciphertext is NEVER returned)
POST/GET /secrets DELETE /secrets/:id
# observability
GET /logs (?groupId&agentId&toolName&status&limit) GET /metrics
GET /agents/:id/inspect POST /agents/:id/invokePOST /a/mcp — agent-wide endpoint: union of tools across the agent's groups
POST /g/:groupId/mcp — Streamable HTTP endpoint (Authorization: Bearer <agent-key>)SSE-Transport – geplant.
Verbinden von Claude / ChatGPT (Web): Schritt-für-Schritt-Anleitung mit Screenshots – docs/connect.md.
Ein Tool, dessen Inhalt Python ist. Nützlich, wenn die Composite-Engine nicht mehr ausreicht: Schleifen, Arithmetik, Parsen, Zusammenfassen vieler Aufrufe in einer Tabelle.
rows = []
for tok in args["tokens"]:
book = await call("market.get_order_book", {"token_id": tok}) # any tool you own
if book["is_error"]:
continue
rows.append(book["structured"])
output = {"count": len(rows), "rows": rows}Im Gültigkeitsbereich: args (die Eingabe des Tools), await call(name, args) → {"text", "structured", "is_error"},
und steps, wenn der Code ein Schritt innerhalb eines Composite ist ({"id": "x", "python": "..."}).
Das Ergebnis ist, was auch immer Sie output zuweisen. Wenn das Skript main definiert, wird stattdessen main(args) aufgerufen (synchron oder asynchron). Wenn keines von beiden → ein expliziter Fehler, niemals ein stilles leeres Ergebnis.
Ein return auf oberster Ebene ist ein Python SyntaxError und tötet das gesamte Skript – weisen Sie output zu,
oder verpacken Sie die Logik in def main(args).
print() wird erfasst und im Tool-Editor angezeigt.
Sandbox. Pyodide (CPython → WASM) in einem Worker-Thread: kein Netzwerk, kein Dateisystem, kein process.
Die Netzwerkmodule von Node werden im Worker blockiert, bevor Pyodide geladen wird, daher schlagen auch Python-Sockets fehl –
der einzige Weg aus einem Skript ist call(...), das durch die normale Tool-Laufzeit (Auth, SSRF-Schutz, Aufrufprotokoll) geht. Ein außer Kontrolle geratenes Skript wird durch Beenden des Workers abgebrochen.
Kosten. Ein Worker pro Verschachtelungsebene, träge gestartet und warm gehalten: erster Lauf nach Start ≈ 1s, folgende Läufe ≈ 10ms. Läufe auf derselben Ebene werden serialisiert, daher verzögert ein langes Skript andere Python-Tools (native/virtuelle Tools sind nicht betroffen). Ein Python-Tool, das ein Python-Tool aufruft, das ein Python-Tool aufruft, ist die Grenze – tiefere Verschachtelung wird abgelehnt.
Standardmäßig deaktiviert. Entweder setzen Sie PYTHON_TOOLS=1 (öffnet die Funktion für jedes Konto auf der Instanz – lokale Entwicklung / Single-User-Self-Host), oder gewähren Sie sie pro Benutzer:
INSERT INTO user_features (id, user_id, feature, enabled)
VALUES (gen_random_uuid()::text, '<user-id>', 'python_tools', true);Das Entfernen der Zeile stoppt auch vorhandene Tools – die ACL wird bei jedem Aufruf erneut überprüft, nicht nur zur Erstellungszeit. Tuning: PYTHON_TOOL_TIMEOUT_MS (30000), PYTHON_TOOL_MAX_CALLS (100),
PYTHON_TOOL_MAX_CODE_BYTES (65536).
Pfad | Zweck |
| Node-Dienst (Fastify + MCP SDK + Drizzle/Postgres) – Control-API + Gateway |
| MCP-Proxy · OpenAPI→Tools · HTTP-Connectors |
| Composite-Engine (Intent-Tools) |
|
|
| Gruppen-Virtual-MCP-Server + Agenten-Authentifizierung |
| node-cron-Registry + JobRun + Self-Cron |
| Tresor (AES-256-GCM) + |
| REST-Endpunkte |
| Drizzle-Schema + pg-Client (Postgres) |
| Web-UI (Vite + React) – Quellen / Tools / V-MCP / Agenten / Geheimnisse / Protokolle |
Entwicklungsdetails – DEVELOPMENT.md.
Geheimnisse werden im Ruhezustand verschlüsselt (AES-256-GCM); der Agent / die Konfiguration sehen nur den Platzhalter ${secret.NAME}, der Wert wird zur Laufzeit eingesetzt.
Ein Agent erhält nur das Toolset seiner Gruppe; Aufrufe werden bei jeder Anfrage durch das Toolset abgesichert.
API-Keys werden als sha256-Hash gespeichert, der Token wird nur einmal angezeigt.
Ein Ausfall eines Upstreams bringt nicht den Endpunkt zum Absturz (Fehlerisolation in der Laufzeit).
Schrittweise entwickelt, Modul für Modul. Alles unten ist implementiert und funktioniert.
✅ Connectors – einen bestehenden MCP-Server als Proxy verwenden, eine REST-API aus OpenAPI 3.x importieren (eigener Parser → Tools) oder einen HTTP-Dienst mit expliziten Endpunkten anbinden.
✅ Tool-Registry & Kuratierung – Tools importieren, umbenennen, Beschreibungen bearbeiten, Sichtbarkeit umschalten, eindeutige Namen pro Besitzer.
✅ Composite-Engine – Intent-Tools, die mehrere Aufrufe nacheinander ausführen; bedingtes when; Templating ($.input.*, $.steps.ID.text); Ausgabevorlage; Trace pro Schritt zur Optimierung.
✅ Gemeinsame Laufzeit (invokeTool) – ein Dispatcher für Gateway, Composites und Scheduler; native→Connector, Composite→Rekursion (tiefenbegrenzt); Fehlerisolation (ein schlechter Upstream bringt den Aufrufer nie zum Absturz).
✅ Gruppen = virtuelles MCP – kuratierte Tools in einem einzigen MCP-Endpunkt bündeln /g/:groupId/mcp (Streamable HTTP).
✅ Agenten – Verbraucheridentitäten mit einem API-Key (sha256-gehasht, einmalig angezeigt) + Key-Rotation.
✅ Agent ↔ V-MCP-Berechtigungen (M2M) – Zugriff pro Gruppe gewähren/entziehen; ein Agent kann viele Gruppen-Endpunkte erreichen; der Key funktioniert nur für gewährte Gruppen.
✅ Scheduler — Cron-Registry (node-cron), JobRun-Log, sofortige Ausführung, wird beim Start geladen.
✅ Self-cron über MCP — integrierte schedule_task / list_schedules / cancel_schedule-Werkzeuge innerhalb einer Gruppe; ein verbundener Agent plant sich selbst.
✅ Vault — Anmeldeinformationen ruhend verschlüsselt (AES-256-GCM); zur Laufzeit über ${secret.NAME} injiziert; Agents/Konfiguration sehen den Wert nie.
✅ Quellbereichsbezogene Secrets — gleicher Name kann pro Quelle existieren; bereichsbezogen überschreibt global.
✅ Statische Authentifizierung — Bearer/API-Key/Benutzerdefinierte Header, Basic (Benutzername/Passwort).
✅ Dynamische Token-Abläufe — oauth2_client_credentials, token_request (Login→JSON-Pfad), oauth2_refresh (zwischengespeichert + automatische Aktualisierung).
✅ Benutzer-OAuth — oauth2_authorization_code (Connect-Fluss) und MCP-natives OAuth (mcp_oauth: SDK-Erkennung + DCR + PKCE + Aktualisierung, mit optionalem vorregistriertem clientId).
✅ Authentifizierung — E-Mail/Passwort (scrypt) + HS256-Sitzungs-JWTs; Registrierung / Anmeldung / Ich.
✅ Mehrbenutzer-Isolation — jede Ressource gehört einem Benutzer; alle Routen durch den Eigentümer begrenzt; Werkzeuge lösen nur innerhalb des Namensraums des Eigentümers auf. Kein kontenübergreifender Zugriff.
✅ Aufrufprotokolle — wer/welches Werkzeug/Status/Dauer/Token-Schätzung pro Aufruf.
✅ Metriken — Gesamtzahlen + nach Werkzeug + nach Agent.
✅ Inspektor & Testaufruf — sehen, was ein Agent pro gewährtem V-MCP sieht; jedes Werkzeug ausführen, um die rohe Antwort anzuzeigen.
✅ Authentifizierung — Anmeldung / Registrierung, Token-Sperre, Abmeldung.
✅ Formular ⟷ JSON-Ersteller für Quellen und Zusammensetzungen (Formular oder rohes JSON bearbeiten, bidirektional).
✅ Inline-Secrets im Quellen-Assistenten (auf die Quelle beschränkt).
✅ Gruppierte, einklappbare, durchsuchbare Werkzeugauswahl & -register (skalierbar auf große importierte APIs).
✅ Verbindungsausschnitte pro V-MCP (claude mcp add …, curl) mit Kopierschaltflächen.
✅ Registerkarten: Quellen · Werkzeuge · V-MCP · Agents · Secrets · Protokolle.
✅ Postgres über Drizzle (Migrationen werden beim Start automatisch angewendet).
✅ Docker Compose für lokales Postgres + Makefile (make setup / make dev / make db-*).
✅ .env-Laden, generierte Entwicklungs-Secrets.
⬜ Organisations-/Projektebene (Teams, Freigabe).
⬜ SSE-Transport auf dem Gateway (heute nur Streamable HTTP).
⬜ Hot-Reload tools/changed-Benachrichtigungen.
⬜ OpenAPI-Endpunkt für ein Werkzeugset; Ablaufverfolgungen.
Ratenbegrenzung /auth (Passwort-Brute-Force), das Gateway und Kontingente pro Agent.
Den Scheduler mehrfach-Replikat-sicher machen (Postgres-Advisory-Lock oder dedizierter Worker) — heute feuert der In-Memory-Cron N-mal mit N Instanzen.
Migrationen in einen separaten Bereitstellungsschritt verschieben (sie laufen bei jedem Instanzstart → Wettlauf mit mehreren Replikaten).
JWT-Widerruf — kurzlebige Zugriffs- + Aktualisierungstoken (ein durchgesickertes 7-Tage-Token kann nicht ungültig gemacht werden; Abmeldung ist nur lokal).
Secret-Verwaltung — KMS + Rotation für VAULT_KEY / JWT_SECRET; CORS verschärfen (Standard ist *); den TLS-Reverse-Proxy dokumentieren.
Die Web-Benutzeroberfläche für die Produktion bereitstellen (dist hinter einem CDN/Proxy bauen & bereitstellen; heute nur Vite-Entwicklung).
Paginierung bei Listenendpunkten (Werkzeuge, Protokolle).
Scheduler-Wiederholung / Backoff / Benachrichtigungen.
OpenAPI-Parser — komplexe Spezifikationen verarbeiten (allOf, tiefe $ref).
Passwort-Zurücksetzen / E-Mail-Verifizierung; Benutzer-Audit-Protokoll.
Verpackt als OCI-Image (ghcr.io/comind-pro/comind-mcp) und gelistet im
offiziellen MCP-Register (registry.modelcontextprotocol.io) — die kanonische
Quelle, die nachgelagerte Kataloge (PulseMCP, Smithery, Docker Hub, …) konsumieren. Die
Metadaten leben in server.json unter dem GitHub-verifizierten
Namespace io.github.comind-pro/comind-mcp.
Führen Sie das Image aus (Null-Infrastruktur, eingebettetes Postgres):
docker run -p 8787:8787 -v comind-data:/data \
-e SERVER_ENV=dev ghcr.io/comind-pro/comind-mcp:latest
# prod: drop SERVER_ENV=dev and set VAULT_KEY + JWT_SECRETDas Veröffentlichen ist automatisiert — einen Versions-Tag pushen und CI (release.yml)
erstellt & pusht das Image zu GHCR, veröffentlicht dann server.json im Register
über GitHub OIDC (keine Tokens):
git tag v0.2.0 && git push origin v0.2.0Hinweis: ComindMCP ist ein Gateway für mehrere Mandanten (HTTP MCP unter
/g/:slug/mcp, Agent-Key-Authentifizierung), kein einzelner stdio-Server — Register-Clients stellen es selbst bereit und verbinden ihre eigenen Agents.
comind-mcp ist Open Source (MIT) und Beiträge sind willkommen — Fehlerberichte, Funktionen, Dokumentationen, Tests.
Forken & Branch von main (feat/..., fix/...).
Lokal einrichten — siehe DEVELOPMENT.md. Kurzfassung: corepack enable && pnpm install, dann pnpm dev.
Vor dem Öffnen eines PR: pnpm typecheck und pnpm -r test müssen bestehen.
Conventional Commits für Nachrichten verwenden (feat:, fix:, docs:, chore:).
Einen PR gegen comind-pro/comind-mcp mit einer klaren Beschreibung öffnen; auf ein zugehöriges Issue verlinken.
Fragen oder Ideen? Öffnen Sie ein Issue. Siehe CONTRIBUTING.md für Details.
MIT © comind — Open Source, kostenlos nutzbar, modifizierbar und überall verteilbar, auch kommerziell.
Repository: https://github.com/comind-pro/comind-mcp
Returns a structured overview of ComindMCP: its name, version, what it does, the repository, and the gateway endpoint shape. Takes no arguments. Call this first to learn what this server is and how agents consume it before using the other comind.* tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| note | No | |
| what | Yes | One-paragraph explanation of the gateway. |
| version | Yes | |
| repository | No | |
| gateway_endpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds context about what is returned (structured overview) and that it takes no arguments, but does not disclose additional behavioral traits beyond what annotations imply. It contradicts nothing.
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, efficient and front-loaded with purpose and usage. Every sentence adds value; no redundancy.
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, output schema present (indicated but not shown), and rich annotations, the description fully addresses what agents need: content, safety, and ordering.
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; the description correctly notes 'Takes no arguments.' With 0 parameters, baseline is 4, and the description adds no extra meaning but is accurate.
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 it returns a structured overview of ComindMCP, listing specific content (name, version, etc.) and distinguishes it from siblings by noting it's the introductory tool.
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 to learn what this server is... before using the other comind.* tools,' providing clear guidance on when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full environment-variable reference for deploying the gateway — each variable with its requirement, default, secret flag and purpose. Takes no arguments. Use this to assemble the env for a production deployment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| env | No | |
| image | No | |
| repository | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, non-destructive. The description adds value by detailing the content (each variable with requirement, default, secret flag, purpose), which goes beyond the annotations. No contradictions.
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 two sentences: first states what it returns, second states its usage. Every sentence adds value, no wasted words, and the main purpose is front-loaded.
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 zero parameters, an output schema, and a straightforward purpose, the description fully covers what the tool does and when to use it. It mentions the specific fields in the returned reference, so it is complete.
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?
There are zero parameters, so schema coverage is 100%. The description explicitly says 'Takes no arguments,' confirming this. No additional parameter information is needed, earning a baseline 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 that the tool returns the full environment-variable reference for deploying the gateway, including specifics about each variable (requirement, default, secret flag, purpose). This distinguishes it from siblings like comind.about or comind.self_host.
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 advises when to use it: 'Use this to assemble the env for a production deployment.' It does not mention when not to use it or alternatives, but given zero parameters and clear purpose, this is adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns ready-to-use commands for connecting a running gateway group endpoint from an MCP client: the HTTP endpoint + Bearer header, a claude mcp add line, an mcp-proxy stdio bridge, and a raw JSON-RPC curl. Takes no arguments. Use this once you have a deployed gateway, a group id and an agent key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| clients | No | Per-client connection commands. |
| summary | No | |
| endpoint | No | |
| auth_header | No | |
| agent_wide_endpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds beyond this by detailing the constructed commands (HTTP, bearer, etc.) and confirms the tool is safe (no side effects). No contradiction with annotations.
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 short sentences: the first lists the output, the second states prerequisites. No wasted words, front-loaded with key information.
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 an existing output schema, the description covers what the tool returns and when to use it. It does not repeat output schema details, which is appropriate. Completeness is high for this simple tool.
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?
There are no parameters (empty input schema), and schema coverage is 100%. The description correctly notes 'Takes no arguments', which aligns with the schema. No further parameter semantics 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?
The description explicitly states what the tool returns: ready-to-use commands (HTTP endpoint, Bearer header, claude mcp add line, mcp-proxy bridge, raw JSON-RPC curl). This clearly distinguishes it from sibling tools like 'about', 'config', 'openapi_example', and 'self_host', which serve different purposes.
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 says 'Use this once you have a deployed gateway, a group id and an agent key', providing clear prerequisites and context. It does not explicitly mention when not to use it or alternatives, but given the narrow scope, this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a worked, copy-paste example of turning an OpenAPI 3.x API into curated MCP tools through the gateway: the ordered steps, the POST /sources body (spec URL or inline spec + baseUrl + secret-templated headers), and the resulting tool name. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| steps | No | |
| result | No | |
| summary | No | |
| create_source | No | POST /sources request body. |
| inline_spec_alternative | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations by detailing what the example includes (ordered steps, POST body details, tool name), consistent with a safe read operation.
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, efficient sentence that front-loads the key result. It is concise but could be slightly more structured with bullet points; however, it earns its place with no waste.
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 zero-parameter tool with an output schema, the description fully covers what the tool returns and the context (OpenAPI to MCP conversion example). No gaps remain.
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?
With zero parameters and 100% schema description coverage, the description adds no parameter info, which is appropriate. Baseline score 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 the tool returns a worked, copy-paste example of converting OpenAPI 3.x APIs into MCP tools, specifying included components (ordered steps, POST body, tool name). It distinguishes itself from siblings like 'comind.config' and 'comind.self_host' by focusing on example generation.
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 implies usage for obtaining an example but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. The purpose is clear, but explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the copy-paste Docker command to run your own ComindMCP gateway plus the available run modes (embedded Postgres via PGlite, external Postgres, or in-memory). Takes no arguments. Call this when you want to deploy or evaluate the full gateway.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| run_modes | No | |
| docker_run | No | Ready-to-run command for a zero-infra instance. |
| repository | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by mentioning the returned Docker command and run modes, but does not disclose additional behavioral traits beyond what annotations indicate, which is acceptable.
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 two sentences, front-loaded with the core action ('Returns the copy-paste Docker command'), and the second sentence provides usage context. Every sentence is necessary and 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?
For a zero-parameter tool with an output schema, the description adequately covers what the tool returns and when to use it. No additional information is needed given the tool's simplicity.
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?
There are no parameters, and the schema coverage is 100%. The description mentions 'Takes no arguments', which is consistent but does not add meaning beyond the schema. Baseline score of 3 applies.
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 that the tool returns a Docker command for self-hosting the gateway, with specific mention of available run modes. It distinguishes itself from sibling tools like comind.about (info) and comind.config (configuration) by focusing on deployment.
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 says 'Call this when you want to deploy or evaluate the full gateway', providing clear context for when to use. However, it does not explicitly state when not to use, though the sibling tools cover other use cases.
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.
v1.0.1comind.about2 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "gateway_endpoint": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "repository": {
+ "format": "uri",
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "what": {
+ "description": "One-paragraph explanation of the gateway.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "version",
+ "what"
+ ],
+ "type": "object"
+}comind.config2 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "env": {
+ "items": {
+ "properties": {
+ "default": {
+ "type": "string"
+ },
+ "desc": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "required": {
+ "type": "boolean"
+ },
+ "secret": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "image": {
+ "type": "string"
+ },
+ "repository": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}comind.mcp_proxy_example2 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "agent_wide_endpoint": {
+ "type": "string"
+ },
+ "auth_header": {
+ "type": "string"
+ },
+ "clients": {
+ "description": "Per-client connection commands.",
+ "type": "object"
+ },
+ "endpoint": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}comind.openapi_example2 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "create_source": {
+ "description": "POST /sources request body.",
+ "type": "object"
+ },
+ "inline_spec_alternative": {
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "result": {
+ "type": "string"
+ },
+ "steps": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}comind.self_host2 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "docker_run": {
+ "description": "Ready-to-run command for a zero-infra instance.",
+ "type": "string"
+ },
+ "repository": {
+ "format": "uri",
+ "type": "string"
+ },
+ "run_modes": {
+ "items": {
+ "properties": {
+ "database_url": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "use_for": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}v1.0.0comind.aboutcomind.configcomind.mcp_proxy_examplecomind.openapi_examplecomind.self_hostScored across 5 tools
Each tool returns a distinct type of documentation (overview, config, connection examples, OpenAPI integration, self-hosting), with no overlap in purpose.
All tool names follow the pattern comind.<descriptive_noun_phrase> with consistent use of underscores, e.g., mcp_proxy_example, self_host.
With 5 tools, the server covers key aspects of ComindMCP documentation without being excessive or insufficient for its informational purpose.
The tools cover major reference areas (overview, config, connection, OpenAPI, self-host). Missing minor aspects like troubleshooting, but core needs are met.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Unified gateway exposing 150+ tools across all NexGenData MCP servers via one endpoint.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.