Skip to main content
Glama
deenesjakoruzh
comind-pro

comind-mcp

Official
by comind-pro
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

comind-mcp

License: MIT

comind-mcp MCP server

Репозиторий: https://github.com/comind-pro/comind-mcp

MCP-шлюз — соединяет различные MCP-серверы и REST API, позволяет курировать и комбинировать инструменты, организовывать их в группы (каждая = отдельный виртуальный MCP-сервер с единой конечной точкой) и раздавать их агентам. Агент видит только узкий набор инструментов, назначенных ему, и может планировать свои собственные cron-задачи через MCP.

Самостоятельное размещение: один Node-сервис + Postgres. Многопользовательский режим с изоляцией по аккаунтам.

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 / Metrics

Быстрый старт

Предварительные требования: Node 20+, pnpm 9 (corepack enable), Docker (локальный Postgres).

make setup        # install deps, start Postgres, apply migrations
make dev          # Postgres + server :8787 + web :5173

  • Веб-интерфейс — http://localhost:5173 (зарегистрируйте аккаунт, затем войдите)

  • Шлюз + Control API — http://localhost:8787 (GET /healthz)

  • Postgres — запускается в Docker (docker compose); в .env репозитория указан хост-порт 5434

Смотрите make help для всех целей. Базовые pnpm-скрипты (pnpm dev, pnpm dev:server, pnpm dev:web) по-прежнему работают, но не управляют контейнером Postgres.

Режимы базы данных

Хранилище выбирается схемой DATABASE_URL — одинаковая схема, одинаковые миграции:

DATABASE_URL

Режим

Назначение

postgres://…

Внешний Postgres

Продакшн, несколько экземпляров (горизонтальное масштабирование).

file:/data/comind

Встроенный Postgres (PGlite)

Самостоятельное размещение без инфраструктуры, один контейнер, демо, Glama.

memory:

Встроенный, в памяти

Одноразовые / CI-тесты.

PGlite это Postgres (WASM), поэтому всё (jsonb, percentile_cont, миграции) работает без изменений — внешний процесс БД не нужен. Персистентность: каталог file: — это реальный каталог данных Postgres; смонтируйте его как том (например, /data), чтобы сохранять данные между релизами. Миграции аддитивны и идемпотентны, поэтому обновление никогда не удаляет существующие данные. Встроенный режим — одноузловой (без нескольких экземпляров — один писатель).

# zero-infra: no Docker/Postgres needed
DATABASE_URL=file:/data/comind SERVER_ENV=dev pnpm --filter comind-server start

Related MCP server: Figma MCP Server

Сквозной сценарий

  1. Источники → добавьте источник (MCP-прокси, OpenAPI или HTTP) → Тест → Импорт инструментов.

  2. Инструменты → переименуйте / скройте ненужные / соберите композитный (инструмент-намерение из нескольких вызовов).

  3. Группы → создайте группу → отметьте набор инструментов (флажки) → (опционально) добавьте расписание.

  4. Агенты → создайте агента в группе → получите API-ключ (один раз) + конечную точку MCP.

  5. Подключите любой MCP-клиент к http://localhost:8787/g/<groupId>/mcp с заголовком Authorization: Bearer <key>. Клиент видит только набор инструментов группы (+ инструменты самопланирования).

  6. Логи → вызовы, метрики, ошибки.

Понятия

Термин

Описание

Источник

Верхнеуровневый: другой MCP-сервер (прокси), REST API (OpenAPI 3.x → инструменты) или HTTP-сервис с явными конечными точками

Инструмент

Один вызов. native (проксируется из источника), composite (сохранённое многошаговое намерение), virtual (шаблон HTTP-запроса) или python (скрипт в песочнице)

Composite

Детерминированно выполняет несколько вызовов и собирает единый результат (шаблон вывода, $.input.*/$.steps.ID.*)

Python-инструмент

Тело на Python, выполняемое в WASM-песочнице — без сети, без файловой системы. Обращается к другим инструментам через await call(...). По умолчанию отключён (см. ниже)

Группа

Виртуальный MCP-сервер: курируемый набор инструментов, доступный через единую конечную точку /g/:groupId/mcp

Агент

Потребитель, привязанный к группе через API-ключ. Видит только набор инструментов группы

Самопланирование

MCP-инструменты schedule_task / list_schedules / cancel_schedule внутри группы — агент планирует сам себя. Отключается по рабочему пространству (Workspaces → Schedules): инструменты исчезают из tools/list агента, вызовы отклоняются, а уже созданные им cron-задачи приостанавливаются до повторного включения. Ваши собственные расписания в этом рабочем пространстве продолжают работать

Секрет

Зашифрованное учётное данное (AES-256-GCM) или ссылка на переменную окружения. Подставляется во время выполнения через ${secret.NAME}; агент его никогда не видит

API (Control Plane, REST на :8787)

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/invoke

Шлюз (для агентов, MCP)

POST /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 — запланирован.

Подключение из Claude / ChatGPT (веб): пошаговое руководство со скриншотами — docs/connect.md.

Python-инструменты

Инструмент, тело которого — Python. Полезен там, где возможностей composite-движка не хватает: циклы, арифметика, парсинг, свёртка множества вызовов в одну таблицу.

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}

  • В области видимости: args (входные данные инструмента), await call(name, args) → {"text", "structured", "is_error"}, и steps, когда код является шагом внутри composite ({"id": "x", "python": "..."}).

  • Результат — это то, что вы присваиваете output. Если скрипт определяет main, вызывается main(args) (синхронно или асинхронно). Ни то, ни другое → явная ошибка, никогда не тихий пустой результат.

  • return на верхнем уровне — это SyntaxError в Python и убивает весь скрипт — присваивайте output или оборачивайте логику в def main(args).

  • print() перехватывается и показывается в редакторе инструмента.

Песочница. Pyodide (CPython → WASM) в рабочем потоке: без сети, без файловой системы, без process. Модули сети Node блокируются в рабочем потоке до загрузки Pyodide, поэтому сокеты Python тоже не работают — единственный выход из скрипта — call(...), который проходит через обычную среду выполнения инструментов (аутентификация, защита SSRF, журнал вызовов). Вышедший из-под контроля скрипт убивается завершением рабочего потока.

Стоимость. Один рабочий поток на уровень вложенности, запускается лениво и держится тёплым: первый запуск после старта ≈ 1 с, последующие ≈ 10 мс. Запуски на одном уровне сериализуются, поэтому длинный скрипт задерживает другие python-инструменты (нативные/виртуальные инструменты не затрагиваются). Python-инструмент, вызывающий python-инструмент, вызывающий python-инструмент — это предел; более глубокая вложенность отклоняется.

По умолчанию отключён. Либо установите PYTHON_TOOLS=1 (открывает функцию для всех аккаунтов на экземпляре — локальная разработка / однопользовательское самостоятельное размещение), либо предоставьте её по пользователю:

INSERT INTO user_features (id, user_id, feature, enabled)
VALUES (gen_random_uuid()::text, '<user-id>', 'python_tools', true);

Отзыв строки также останавливает существующие инструменты — ACL проверяется при каждом вызове, а не только во время создания. Настройка: PYTHON_TOOL_TIMEOUT_MS (30000), PYTHON_TOOL_MAX_CALLS (100), PYTHON_TOOL_MAX_CODE_BYTES (65536).

Структура

Путь

Назначение

server/

Node-сервис (Fastify + MCP SDK + Drizzle/Postgres) — control API + шлюз

server/src/connectors/

MCP-прокси · OpenAPI→инструменты · HTTP-коннекторы

server/src/composite/

Composite-движок (инструменты-намерения)

server/src/runtime/

invokeTool — общая среда выполнения (шлюз / composite / планировщик) + песочница Pyodide

server/src/gateway/

Виртуальный MCP-сервер группы + аутентификация агента

server/src/scheduler/

Реестр node-cron + JobRun + самопланирование

server/src/secrets/

Хранилище (AES-256-GCM) + подстановка ${secret.X}

server/src/routes/

REST-конечные точки

server/src/db/

Схема Drizzle + клиент pg (Postgres)

web/

Веб-интерфейс (Vite + React) — Источники / Инструменты / V-MCP / Агенты / Секреты / Логи

Детали разработки — DEVELOPMENT.md.

Безопасность

  • Секреты шифруются в покое (AES-256-GCM); агент/конфигурация видят только плейсхолдер ${secret.NAME}, значение подставляется во время выполнения.

  • Агент получает только набор инструментов своей группы; вызовы проверяются по набору инструментов при каждом запросе.

  • API-ключи хранятся в виде хеша sha256, токен показывается один раз.

  • Сбой одного вышестоящего сервиса не приводит к падению конечной точки (изоляция ошибок в среде выполнения).

Модули и возможности

Строится итеративно, модуль за модулем. Всё ниже реализовано и работает.

Основной шлюз

  • ✅ Коннекторы — проксирование существующего MCP-сервера, импорт REST API из OpenAPI 3.x (собственный парсер → инструменты) или подключение HTTP-сервиса с явными конечными точками.

  • ✅ Реестр инструментов и курирование — импорт инструментов, переименование, редактирование описаний, переключение видимости, уникальные имена на владельца.

  • ✅ Composite-движок — инструменты-намерения, выполняющие несколько вызовов последовательно; условный when; шаблонизация ($.input.*, $.steps.ID.text); шаблон вывода; пошаговая трассировка для настройки.

  • ✅ Общая среда выполнения (invokeTool) — один диспетчер для шлюза, композитов и планировщика; native→коннектор, composite→рекурсия (с ограничением глубины); изоляция ошибок (плохой вышестоящий сервис никогда не крашит вызывающего).

  • ✅ Группы = виртуальный MCP — объединение курируемых инструментов в единую MCP-конечную точку /g/:groupId/mcp (Streamable HTTP).

  • ✅ Агенты — идентификаторы потребителей с одним API-ключом (sha256-хеширован, показывается один раз) + ротация ключей.

  • ✅ Разрешения агент ↔ V-MCP (M2M) — предоставление/отзыв доступа по группам; один агент может достигать многих конечных точек групп; ключ работает только для предоставленных групп.

Планирование

  • ✅ Scheduler — cron registry (node-cron), JobRun log, run-now, loaded on boot.

  • ✅ Self-cron over MCP — built-in schedule_task / list_schedules / cancel_schedule tools inside a group; a connected agent schedules itself.

Secrets & auth-to-upstreams

  • ✅ Vault — credentials encrypted at rest (AES-256-GCM); injected at runtime via ${secret.NAME}; agents/config never see the value.

  • ✅ Source-scoped secrets — same name can exist per source; scoped overrides global.

  • ✅ Static auth — bearer/api-key/custom headers, basic (username/password).

  • ✅ Dynamic token flows — oauth2_client_credentials, token_request (login→JSON-path), oauth2_refresh (cached + auto-refresh).

  • ✅ User OAuth — oauth2_authorization_code (Connect flow) and MCP-native OAuth (mcp_oauth: SDK discovery + DCR + PKCE + refresh, with optional pre-registered clientId).

Accounts & isolation

  • ✅ Auth — email/password (scrypt) + HS256 session JWTs; register / login / me.

  • ✅ Multi-user isolation — every resource is owned by a user; all routes scoped by owner; tools resolve only within the owner's namespace. No cross-account access.

Observability

  • ✅ Call logs — who/which tool/status/duration/token estimate per invocation.

  • ✅ Metrics — totals + by-tool + by-agent.

  • ✅ Inspector & test-invoke — see what an agent sees per granted V-MCP; run any tool to view the raw response.

Web UI (Vite + React)

  • ✅ Auth — login / register, token gating, logout.

  • ✅ Form ⟷ JSON builders for sources and composites (edit a form or the raw JSON, two-way).

  • ✅ Inline secrets in the source wizard (scoped to the source).

  • ✅ Grouped, collapsible, searchable tool picker & registry (scales to large imported APIs).

  • ✅ Connect snippets per V-MCP (claude mcp add …, curl) with copy buttons.

  • ✅ Tabs: Sources · Tools · V-MCP · Agents · Secrets · Logs.

Infrastructure

  • ✅ Postgres via Drizzle (migrations auto-applied on boot).

  • ✅ Docker Compose for local Postgres + Makefile (make setup / make dev / make db-*).

  • ✅ .env loading, generated dev secrets.

Not yet (optional next)

  • ⬜ Org / project layer (teams, sharing).

  • ⬜ SSE transport on the gateway (Streamable HTTP only today).

  • ⬜ Hot-reload tools/changed notifications.

  • ⬜ OpenAPI endpoint for a toolset; traces.

Roadmap

  • Rate-limit /auth (password brute-force), the gateway, and per-agent quotas.

  • Make the scheduler multi-replica safe (Postgres advisory lock or a dedicated worker) — today in-memory cron fires N times with N instances.

  • Move migrations to a separate deploy step (they run on every instance boot → race with multiple replicas).

  • JWT revocation — short-lived access + refresh tokens (a leaked 7-day token can't be invalidated; logout is local-only).

  • Secret management — KMS + rotation for VAULT_KEY / JWT_SECRET; tighten CORS (defaults to *); document the TLS reverse proxy.

  • Serve the web UI for production (build & serve dist behind a CDN/proxy; Vite dev only today).

  • Pagination on list endpoints (tools, logs).

  • Scheduler retry / backoff / alerting.

  • OpenAPI parser — handle complex specs (allOf, deep $ref).

  • Password reset / email verification; user audit log.

Distribution

Packaged as an OCI image (ghcr.io/comind-pro/comind-mcp) and listed in the official MCP Registry (registry.modelcontextprotocol.io) — the canonical source that downstream catalogs (PulseMCP, Smithery, Docker Hub, …) consume. The metadata lives in server.json under the GitHub-verified namespace io.github.comind-pro/comind-mcp.

Run the image (zero-infra, embedded 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_SECRET

Releasing is automated — push a version tag and CI (release.yml) builds & pushes the image to GHCR, then publishes server.json to the registry via GitHub OIDC (no tokens):

git tag v0.2.0 && git push origin v0.2.0

Note: ComindMCP is a multi-tenant gateway (HTTP MCP at /g/:slug/mcp, agent-key auth), not a single stdio server — registry clients self-deploy it and connect their own agents.

Contributing

comind-mcp is open source (MIT) and contributions are welcome — bug reports, features, docs, tests.

  1. Fork & branch from main (feat/..., fix/...).

  2. Set up locally — see DEVELOPMENT.md. TL;DR: corepack enable && pnpm install, then pnpm dev.

  3. Before opening a PR: pnpm typecheck and pnpm -r test must pass.

  4. Use Conventional Commits for messages (feat:, fix:, docs:, chore:).

  5. Open a PR against comind-pro/comind-mcp with a clear description; link any related issue.

Questions or ideas? Open an issue. See CONTRIBUTING.md for details.

License

MIT © comind — open source, free to use, modify, and distribute anywhere, including commercially.

Repository: https://github.com/comind-pro/comind-mcp

Available Tools

5 tools
comind.aboutAbout ComindMCPA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
nameYes
noteNo
whatYesOne-paragraph explanation of the gateway.
versionYes
repositoryNo
gateway_endpointNo

TDQS

A4.7/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

comind.configDeployment config referenceA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
envNo
imageNo
repositoryNo

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

comind.mcp_proxy_exampleExample — connect a V-MCP endpointA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteNo
clientsNoPer-client connection commands.
summaryNo
endpointNo
auth_headerNo
agent_wide_endpointNo

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

comind.openapi_exampleExample — OpenAPI → MCP toolsA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteNo
stepsNo
resultNo
summaryNo
create_sourceNoPOST /sources request body.
inline_spec_alternativeNo

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

comind.self_hostSelf-host the gatewayA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
run_modesNo
docker_runNoReady-to-run command for a zero-infra instance.
repositoryNo

TDQS

A4.1/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv1.0.1
    • Changedcomind.about2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput 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"
+}
    • Changedcomind.config2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput 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"
+}
    • Changedcomind.mcp_proxy_example2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput 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"
+}
    • Changedcomind.openapi_example2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput 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"
+}
    • Changedcomind.self_host2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput 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"
+}
  2. 5 tool updatesv1.0.0
    • First observedcomind.about
    • First observedcomind.config
    • First observedcomind.mcp_proxy_example
    • First observedcomind.openapi_example
    • First observedcomind.self_host
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool returns a distinct type of documentation (overview, config, connection examples, OpenAPI integration, self-hosting), with no overlap in purpose.

Naming Consistency5/5

All tool names follow the pattern comind.<descriptive_noun_phrase> with consistent use of underscores, e.g., mcp_proxy_example, self_host.

Tool Count5/5

With 5 tools, the server covers key aspects of ComindMCP documentation without being excessive or insufficient for its informational purpose.

Completeness4/5

The tools cover major reference areas (overview, config, connection, OpenAPI, self-host). Missing minor aspects like troubleshooting, but core needs are met.

Maintenance

ActivityMaintained
ResponsivenessNo issues

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

Related MCP Servers

  • MCP Starter Server

    MatthewDailey
    A
    license
    C
    quality
    D
    maintenance
    This server provides a minimal template for creating AI assistant tools using the ModelContextProtocol, featuring a simple 'hello world' tool example and development setups for building custom MCP tools.
    1
    89
    14
    -

  • Figma MCP Server

    MatthewDailey
    F
    license
    B
    quality
    D
    maintenance
    Enables AI assistants to interact with Figma files through the ModelContextProtocol, allowing viewing, commenting, and analyzing Figma designs directly in chat interfaces.
    5
    2,160
    213
    -

  • MCPilot

    ferrary7
    F
    license
    C
    quality
    D
    maintenance
    A 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
    -

  • MCP-Hive Proxy

    MCP-Hive
    A
    license
    Not graded
    quality
    D
    maintenance
    A gateway server that enables agentic hosts to access multiple MCP servers through a single namespaced connection or proxy a specific server from MCP-Hive. It provides built-in discovery tools to list available servers, tools, and resources for seamless integration.
    115
    Apache 2.0

Latest Blog Posts

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/comind-pro/comind-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server