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

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

MCP gateway — connects various MCP servers and REST APIs, lets you curate and combine tools, organize them into groups (each = a separate virtual MCP server with a single endpoint) and hand them out to agents. An agent sees only the narrow set of tools assigned to it and can schedule its own crons through MCP.

Self-hosted: a single Node service + Postgres. Multi-user with per-account isolation.

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

Quick start

Prerequisites: Node 20+, pnpm 9 (corepack enable), Docker (local Postgres).

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

See make help for all targets. Underlying pnpm scripts (pnpm dev, pnpm dev:server, pnpm dev:web) still work but don't manage the Postgres container.

Database modes

The store is selected by the DATABASE_URL scheme — same schema, same migrations:

DATABASE_URL

Mode

Use for

postgres://…

External Postgres

Production, multi-instance (horizontal scale).

file:/data/comind

Embedded Postgres (PGlite)

Zero-infra self-host, single container, demos, Glama.

memory:

Embedded, in-memory

Throwaway / CI smoke.

PGlite is Postgres (WASM), so everything (jsonb, percentile_cont, migrations) runs unchanged — no external DB process. Persistence: the file: directory is a real Postgres data dir; mount it as a volume (e.g. /data) to keep data across releases. Migrations are additive and idempotent, so an upgrade never wipes existing data. Embedded mode is single-node (no multi-instance — one writer).

# 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

End-to-end scenario

  1. Sources → add a source (MCP proxy, OpenAPI, or HTTP) → Test → Import tools.

  2. Tools → rename / hide the unnecessary / assemble a composite (an intent tool from several calls).

  3. Groups → create a group → mark the toolset (checkboxes) → (optional) add a schedule.

  4. Agents → create an agent in the group → get an API key (once) + MCP endpoint.

  5. Connect any MCP client to http://localhost:8787/g/<groupId>/mcp with Authorization: Bearer <key>. The client sees only the group's toolset (+ self-cron tools).

  6. Logs → calls, metrics, errors.

Concepts

Term

What it is

Source

Upstream: another MCP server (proxy), a REST API (OpenAPI 3.x → tools), or an HTTP service with explicit endpoints

Tool

A single call. native (proxied from a source), composite (a saved multi-step intent), virtual (an HTTP request template) or python (a sandboxed script)

Composite

Deterministically runs several calls and assembles a single result (output template, $.input.*/$.steps.ID.*)

Python tool

A body of Python run in a WASM sandbox — no network, no filesystem. Reaches other tools via await call(...). Off by default (see below)

Group

A virtual MCP server: a curated set of tools, exposed as a single endpoint /g/:groupId/mcp

Agent

A consumer bound to a group via an API key. Sees only the group's toolset

Self-cron

MCP tools schedule_task / list_schedules / cancel_schedule inside a group — the agent schedules itself. Switch it off per workspace (Workspaces → Schedules): the tools disappear from the agent's tools/list, calls are refused, and the crons it already created are paused until it is back on. Your own schedules in that workspace keep running

Secret

An encrypted credential (AES-256-GCM) or an env reference. Substituted at runtime via ${secret.NAME}; the agent never sees it

API (Control Plane, REST on :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

Gateway (for agents, 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 transport — planned.

Connect from Claude / ChatGPT (web): step-by-step guide with screenshots — docs/connect.md.

Python tools

A tool whose body is Python. Useful where the composite engine runs out of road: loops, arithmetic, parsing, folding many calls into one table.

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}

  • In scope: args (the tool's input), await call(name, args) → {"text", "structured", "is_error"}, and steps when the code is a step inside a composite ({"id": "x", "python": "..."}).

  • The result is whatever you assign to output. If the script defines main, main(args) is called instead (sync or async). Neither one → an explicit error, never a silent empty result.

  • A top-level return is a Python SyntaxError and kills the whole script — assign to output, or wrap the logic in def main(args).

  • print() is captured and shown in the tool editor.

Sandbox. Pyodide (CPython → WASM) in a worker thread: no network, no filesystem, no process. Node's network modules are blocked in the worker before Pyodide loads, so Python sockets fail too — the only way out of a script is call(...), which goes through the normal tool runtime (auth, SSRF guard, call log). A runaway script is killed by terminating the worker.

Cost. One worker per nesting level, booted lazily and kept warm: first run after start ≈ 1s, subsequent runs ≈ 10ms. Runs at the same level are serialised, so a long script delays other python tools (native/virtual tools are unaffected). A python tool calling a python tool calling a python tool is the limit — deeper nesting is refused.

Off by default. Either set PYTHON_TOOLS=1 (opens the feature to every account on the instance — local dev / single-user self-host), or grant it per user:

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

Revoking the row stops existing tools too — the ACL is re-checked on every call, not just at authoring time. Tuning: PYTHON_TOOL_TIMEOUT_MS (30000), PYTHON_TOOL_MAX_CALLS (100), PYTHON_TOOL_MAX_CODE_BYTES (65536).

Structure

Path

Purpose

server/

Node service (Fastify + MCP SDK + Drizzle/Postgres) — control API + gateway

server/src/connectors/

MCP proxy · OpenAPI→tools · HTTP connectors

server/src/composite/

Composite engine (intent tools)

server/src/runtime/

invokeTool — shared runtime (gateway / composite / scheduler) + the Pyodide sandbox

server/src/gateway/

Group's virtual MCP server + agent auth

server/src/scheduler/

node-cron registry + JobRun + self-cron

server/src/secrets/

Vault (AES-256-GCM) + ${secret.X} injection

server/src/routes/

REST endpoints

server/src/db/

Drizzle schema + pg client (Postgres)

web/

Web UI (Vite + React) — Sources / Tools / V-MCP / Agents / Secrets / Logs

Development details — DEVELOPMENT.md.

Security

  • Secrets are encrypted at-rest (AES-256-GCM); the agent/config see only the ${secret.NAME} placeholder, the value is substituted at runtime.

  • An agent gets only its group's toolset; calls are gated by toolset on every request.

  • API keys are stored as an sha256 hash, the token is shown once.

  • A failure of one upstream does not bring down the endpoint (fault isolation in the runtime).

Modules & features

Built iteratively, module by module. Everything below is implemented and working.

Core gateway

  • ✅ Connectors — proxy an existing MCP server, import a REST API from OpenAPI 3.x (own parser → tools), or wire an HTTP service with explicit endpoints.

  • ✅ Tool registry & curation — import tools, rename, edit descriptions, toggle visibility, per-owner unique names.

  • ✅ Composite engine — intent tools that run several calls in sequence; conditional when; templating ($.input.*, $.steps.ID.text); output template; per-step trace for tuning.

  • ✅ Shared runtime (invokeTool) — one dispatcher for gateway, composites and scheduler; native→connector, composite→recursion (depth-limited); fault isolation (a bad upstream never crashes the caller).

  • ✅ Groups = virtual MCP — bundle curated tools into a single MCP endpoint /g/:groupId/mcp (Streamable HTTP).

  • ✅ Agents — consumer identities with one API key (sha256-hashed, shown once) + key rotation.

  • ✅ Agent ↔ V-MCP grants (M2M) — grant/revoke access per group; one agent can reach many group endpoints; the key only works for granted groups.

Scheduling

  • ✅ 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