Repositorio: https://github.com/comind-pro/comind-mcp
Puerta de enlace MCP — conecta varios servidores MCP y APIs REST, permite seleccionar y combinar herramientas, organizarlas en grupos (cada uno = un servidor MCP virtual separado con un único endpoint) y distribuirlas a los agentes. Un agente solo ve el conjunto limitado de herramientas que se le asignan y puede programar sus propios cron a través de MCP.
Autoalojado: un único servicio Node + Postgres. Multiusuario con aislamiento por cuenta.
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 / MetricsRequisitos: Node 20+, pnpm 9 (corepack enable), Docker (Postgres local).
make setup # install deps, start Postgres, apply migrations
make dev # Postgres + server :8787 + web :5173Interfaz web — http://localhost:5173 (registrar una cuenta, luego iniciar sesión)
Puerta de enlace + API de control — http://localhost:8787 (GET /healthz)
Postgres — se ejecuta en Docker (docker compose); el .env del repositorio asigna el puerto del host 5434
Consulte make help para todos los objetivos. Los scripts subyacentes de pnpm (pnpm dev, pnpm dev:server, pnpm dev:web) siguen funcionando pero no gestionan el contenedor de Postgres.
El almacén se selecciona mediante el esquema de DATABASE_URL — mismo esquema, mismas migraciones:
| Modo | Uso |
| Postgres externo | Producción, multi-instancia (escala horizontal). |
| Postgres (PGlite) integrado | Autoalojamiento sin infraestructura, contenedor único, demos, Glama. |
| Integrado, en memoria | Desechable / pruebas CI. |
PGlite es Postgres (WASM), por lo que todo (jsonb, percentile_cont, migraciones) funciona sin cambios — sin proceso de base de datos externo. Persistencia: el directorio file: es un directorio de datos real de Postgres; móntelo como un volumen (p. ej., /data) para conservar los datos entre versiones. Las migraciones son aditivas e idempotentes, por lo que una actualización nunca borra los datos existentes. El modo integrado es de un solo nodo (sin multi-instancia — un escritor).
# zero-infra: no Docker/Postgres needed
DATABASE_URL=file:/data/comind SERVER_ENV=dev pnpm --filter comind-server startRelated MCP server: Figma MCP Server
Fuentes → añadir una fuente (proxy MCP, OpenAPI o HTTP) → Probar → Importar herramientas.
Herramientas → renombrar / ocultar las innecesarias / ensamblar una compuesta (una herramienta de intención a partir de varias llamadas).
Grupos → crear un grupo → marcar el conjunto de herramientas (casillas de verificación) → (opcional) añadir una programación.
Agentes → crear un agente en el grupo → obtener una clave API (una vez) + endpoint MCP.
Conectar cualquier cliente MCP a http://localhost:8787/g/<groupId>/mcp con Authorization: Bearer <key>. El cliente solo ve el conjunto de herramientas del grupo (+ herramientas de autocron).
Registros → llamadas, métricas, errores.
Término | Qué es |
Fuente | Ascendente: otro servidor MCP (proxy), una API REST (OpenAPI 3.x → herramientas) o un servicio HTTP con endpoints explícitos |
Herramienta | Una única llamada. |
Compuesta | Ejecuta deterministamente varias llamadas y ensambla un único resultado (plantilla de salida, |
Herramienta Python | Un cuerpo de Python ejecutado en un entorno aislado WASM — sin red, sin sistema de archivos. Accede a otras herramientas mediante |
Grupo | Un servidor MCP virtual: un conjunto seleccionado de herramientas, expuesto como un único endpoint |
Agente | Un consumidor vinculado a un grupo mediante una clave API. Solo ve el conjunto de herramientas del grupo |
Autocron | Herramientas MCP |
Secreto | Una credencial cifrada (AES-256-GCM) o una referencia de entorno. Se sustituye en tiempo de ejecución mediante |
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>)Transporte SSE — planificado.
Conectar desde Claude / ChatGPT (web): guía paso a paso con capturas de pantalla — docs/connect.md.
Una herramienta cuyo cuerpo es Python. Útil cuando el motor compuesto se queda sin camino: bucles, aritmética, análisis, convertir muchas llamadas en una tabla.
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}En alcance: args (la entrada de la herramienta), await call(name, args) → {"text", "structured", "is_error"},
y steps cuando el código es un paso dentro de una compuesta ({"id": "x", "python": "..."}).
El resultado es lo que sea que asigne a output. Si el script define main, se llama a main(args)
en su lugar (síncrono o asíncrono). Si no hay ninguno → un error explícito, nunca un resultado vacío silencioso.
Un return de nivel superior es un SyntaxError de Python y mata todo el script — asigne a output,
o envuelva la lógica en def main(args).
print() se captura y se muestra en el editor de herramientas.
Entorno aislado. Pyodide (CPython → WASM) en un hilo de trabajo: sin red, sin sistema de archivos, sin process.
Los módulos de red de Node están bloqueados en el hilo de trabajo antes de que se cargue Pyodide, por lo que los sockets de Python también fallan —
la única forma de salir de un script es call(...), que pasa por el tiempo de ejecución normal de la herramienta (autenticación, protección SSRF,
registro de llamadas). Un script descontrolado se elimina terminando el hilo de trabajo.
Costo. Un hilo de trabajo por nivel de anidamiento, iniciado de forma diferida y mantenido caliente: primera ejecución después del inicio ≈ 1s, ejecuciones posteriores ≈ 10ms. Las ejecuciones en el mismo nivel se serializan, por lo que un script largo retrasa otras herramientas python (las herramientas nativas/virtuales no se ven afectadas). Una herramienta python que llama a una herramienta python que llama a una herramienta python es el límite — se rechaza un anidamiento más profundo.
Desactivada por defecto. Establezca PYTHON_TOOLS=1 (abre la función para cada cuenta en la
instancia — desarrollo local / autoalojamiento de un solo usuario), o concédala por usuario:
INSERT INTO user_features (id, user_id, feature, enabled)
VALUES (gen_random_uuid()::text, '<user-id>', 'python_tools', true);Revocar la fila también detiene las herramientas existentes — la ACL se vuelve a comprobar en cada llamada, no solo en el
momento de la creación. Ajuste: PYTHON_TOOL_TIMEOUT_MS (30000), PYTHON_TOOL_MAX_CALLS (100),
PYTHON_TOOL_MAX_CODE_BYTES (65536).
Ruta | Propósito |
| Servicio Node (Fastify + MCP SDK + Drizzle/Postgres) — API de control + puerta de enlace |
| Proxy MCP · OpenAPI→herramientas · Conectores HTTP |
| Motor compuesto (herramientas de intención) |
|
|
| Servidor MCP virtual del grupo + autenticación de agente |
| Registro node-cron + JobRun + autocron |
| Bóveda (AES-256-GCM) + inyección |
| Puntos finales REST |
| Esquema Drizzle + cliente pg (Postgres) |
| Interfaz web (Vite + React) — Fuentes / Herramientas / V-MCP / Agentes / Secretos / Registros |
Detalles de desarrollo — DEVELOPMENT.md.
Los secretos se cifran en reposo (AES-256-GCM); el agente/configuración solo ve el marcador de posición ${secret.NAME}, el valor se sustituye en tiempo de ejecución.
Un agente solo obtiene el conjunto de herramientas de su grupo; las llamadas están controladas por el conjunto de herramientas en cada solicitud.
Las claves API se almacenan como un hash sha256, el token se muestra una vez.
Una falla de un ascendente no derriba el endpoint (aislamiento de fallos en el tiempo de ejecución).
Construido de forma iterativa, módulo por módulo. Todo lo siguiente está implementado y funcionando.
✅ Conectores — proxy de un servidor MCP existente, importar una API REST desde OpenAPI 3.x (analizador propio → herramientas), o conectar un servicio HTTP con endpoints explícitos.
✅ Registro y selección de herramientas — importar herramientas, renombrar, editar descripciones, alternar visibilidad, nombres únicos por propietario.
✅ Motor compuesto — herramientas de intención que ejecutan varias llamadas en secuencia; when condicional; plantillas ($.input.*, $.steps.ID.text); plantilla de salida; traza por paso para ajuste.
✅ Tiempo de ejecución compartido (invokeTool) — un despachador para puerta de enlace, compuestos y programador; nativo→conector, compuesto→recursión (limitada por profundidad); aislamiento de fallos (un ascendente defectuoso nunca bloquea al llamante).
✅ Grupos = MCP virtual — agrupar herramientas seleccionadas en un único endpoint MCP /g/:groupId/mcp (HTTP transmisible).
✅ Agentes — identidades de consumidor con una clave API (hash sha256, mostrada una vez) + rotación de claves.
✅ Concesiones Agente ↔ V-MCP (M2M) — conceder/revocar acceso por grupo; un agente puede alcanzar muchos endpoints de grupo; la clave solo funciona para los grupos concedidos.
✅ Scheduler — registro cron (node-cron), registro de ejecución de trabajos, ejecución ahora, cargado al inicio.
✅ Auto-cron vía MCP — herramientas integradas schedule_task / list_schedules / cancel_schedule dentro de un grupo; un agente conectado se auto-programa.
✅ Vault — credenciales cifradas en reposo (AES-256-GCM); inyectadas en tiempo de ejecución mediante ${secret.NOMBRE}; agentes/configuración nunca ven el valor.
✅ Secretos con ámbito por fuente — el mismo nombre puede existir por fuente; el ámbito por fuente anula el ámbito global.
✅ Autenticación estática — encabezados bearer/api-key/personalizados, básico (usuario/contraseña).
✅ Flujos de token dinámicos — oauth2_client_credentials, token_request (inicio de sesión→ruta JSON), oauth2_refresh (en caché + actualización automática).
✅ OAuth de usuario — oauth2_authorization_code (flujo de conexión) y OAuth nativo de MCP (mcp_oauth: descubrimiento SDK + DCR + PKCE + actualización, con clientId opcional previamente registrado).
✅ Autenticación — correo electrónico/contraseña (scrypt) + sesiones JWT HS256; registro / inicio de sesión / perfil.
✅ Aislamiento multiusuario — cada recurso pertenece a un usuario; todas las rutas limitadas por propietario; las herramientas se resuelven solo dentro del espacio de nombres del propietario. Sin acceso entre cuentas.
✅ Registros de llamadas — quién/qué herramienta/estado/duración/estimación de tokens por invocación.
✅ Métricas — totales + por herramienta + por agente.
✅ Inspector y prueba de invocación — ver lo que un agente ve por V-MCP concedido; ejecutar cualquier herramienta para ver la respuesta en bruto.
✅ Autenticación — inicio de sesión / registro, bloqueo por token, cierre de sesión.
✅ Constructores de formulario ⟷ JSON para fuentes y compuestos (editar un formulario o el JSON en bruto, bidireccional).
✅ Secretos en línea en el asistente de fuentes (con ámbito para la fuente).
✅ Selector y registro de herramientas agrupado, plegable y buscable (se adapta a APIs importadas grandes).
✅ Fragmentos de conexión por V-MCP (claude mcp add …, curl) con botones de copia.
✅ Pestañas: Fuentes · Herramientas · V-MCP · Agentes · Secretos · Registros.
✅ Postgres vía Drizzle (migraciones aplicadas automáticamente al inicio).
✅ Docker Compose para Postgres local + Makefile (make setup / make dev / make db-*).
✅ Carga de .env, secretos de desarrollo generados.
⬜ Capa de organización/proyecto (equipos, uso compartido).
⬜ Transporte SSE en la puerta de enlace (solo HTTP Streamable hoy).
⬜ Notificaciones de recarga en caliente de tools/changed.
⬜ Punto final OpenAPI para un conjunto de herramientas; trazas.
Limitar velocidad /auth (fuerza bruta de contraseña), la puerta de enlace y cuotas por agente.
Hacer que el programador sea seguro para múltiples réplicas (bloqueo de asesoramiento de Postgres o un trabajador dedicado) — hoy el cron en memoria se ejecuta N veces con N instancias.
Mover migraciones a un paso de despliegue separado (se ejecutan en cada arranque de instancia → conflicto con múltiples réplicas).
Revocación de JWT — tokens de acceso de corta duración + tokens de actualización (un token filtrado de 7 días no se puede invalidar; el cierre de sesión es solo local).
Gestión de secretos — KMS + rotación para VAULT_KEY / JWT_SECRET; restringir CORS (por defecto a *); documentar el proxy inverso TLS.
Servir la interfaz web para producción (compilar y servir dist detrás de un CDN/proxy; solo Vite dev hoy).
Paginación en puntos finales de listado (herramientas, registros).
Reintento/retroceso/alertas del programador.
Analizador OpenAPI — manejar especificaciones complejas (allOf, $ref profundo).
Restablecimiento de contraseña / verificación de correo electrónico; registro de auditoría de usuario.
Empaquetado como una imagen OCI (ghcr.io/comind-pro/comind-mcp) y listado en el
Registro MCP oficial (registry.modelcontextprotocol.io) — la fuente
canónica que consumen los catálogos descendentes (PulseMCP, Smithery, Docker Hub, …). Los
metadatos residen en server.json bajo el espacio de nombres
verificado por GitHub io.github.comind-pro/comind-mcp.
Ejecutar la imagen (sin infraestructura, Postgres integrado):
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_SECRETEl lanzamiento es automatizado — impulsar una etiqueta de versión y CI (release.yml)
compila y empuja la imagen a GHCR, luego publica server.json al registro
vía GitHub OIDC (sin tokens):
git tag v0.2.0 && git push origin v0.2.0Nota: ComindMCP es una puerta de enlace multiinquilino (HTTP MCP en
/g/:slug/mcp, autenticación por clave de agente), no un servidor stdio único — los clientes del registro lo autodespliegan y conectan sus propios agentes.
comind-mcp es de código abierto (MIT) y las contribuciones son bienvenidas — informes de errores, funcionalidades, documentación, pruebas.
Haz un fork y crea una rama desde main (feat/..., fix/...).
Configura localmente — consulta DEVELOPMENT.md. Resumen: corepack enable && pnpm install, luego pnpm dev.
Antes de abrir un PR: pnpm typecheck y pnpm -r test deben pasar.
Usa Conventional Commits para los mensajes (feat:, fix:, docs:, chore:).
Abre un PR contra comind-pro/comind-mcp con una descripción clara; vincula cualquier problema relacionado.
¿Preguntas o ideas? Abre un issue. Consulta CONTRIBUTING.md para más detalles.
MIT © comind — código abierto, libre de usar, modificar y distribuir en cualquier lugar, incluso comercialmente.
Repositorio: 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.