仓库：https://github.com/comind-pro/comind-mcp
MCP 网关 — 连接各种 MCP 服务器和 REST API，允许你策划和组合工具，将它们组织成组（每个组 = 一个独立的虚拟 MCP 服务器，具有单一端点）并分发给代理。代理只能看到分配给它的那组狭窄工具，并且可以通过 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 :5173Web UI — http://localhost:5173（注册账户，然后登录）
网关 + 控制 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 方案选择 — 相同的模式，相同的迁移：
| 模式 | 用途 |
| 外部 Postgres | 生产环境，多实例（水平扩展）。 |
| 嵌入式 Postgres (PGlite) | 零基础设施自托管，单容器，演示，Glama。 |
| 嵌入式，内存中 | 临时 / 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 startRelated MCP server: Figma MCP Server
源 → 添加一个源（MCP 代理、OpenAPI 或 HTTP）→ 测试 → 导入工具。
工具 → 重命名 / 隐藏不必要的 / 组装一个复合工具（一个由多次调用组成的意图工具）。
组 → 创建一个组 → 标记工具集（复选框）→ （可选）添加一个计划。
代理 → 在组中创建一个代理 → 获取一个 API 密钥（一次性） + MCP 端点。
将任何 MCP 客户端连接到 http://localhost:8787/g/<groupId>/mcp，并带有 Authorization: Bearer <key>。客户端只能看到该组的工具集（+ 自定时任务工具）。
日志 → 调用、指标、错误。
术语 | 含义 |
源 | 上游：另一个 MCP 服务器（代理）、REST API（OpenAPI 3.x → 工具）或具有显式端点的 HTTP 服务 |
工具 | 单个调用。 |
复合工具 | 确定性地运行多个调用并组装单个结果（输出模板， |
Python 工具 | 在 WASM 沙盒中运行的 Python 代码体 — 无网络，无文件系统。通过 |
组 | 一个虚拟 MCP 服务器：一组策划好的工具，通过单个端点 |
代理 | 通过 API 密钥绑定到组的消费者。只能看到该组的工具集 |
自定时任务 | 组内的 MCP 工具 |
密钥 | 加密的凭据（AES-256-GCM）或环境变量引用。运行时通过 |
GET /healthz
# sources
POST/GET /sources GET/PATCH/DELETE /sources/:id
POST /sources/:id/test POST /sources/:id/import
# tools
GET /tools (?sourceId&kind&visible) GET/PATCH/DELETE /tools/:id
# composites
POST/GET /composite-tools GET/DELETE /composite-tools/:id POST /composite-tools/:id/run
# python tools (gated — see "Python tools")
POST /python-tools GET/PATCH/DELETE /python-tools/:id
POST /python-tools/test POST /python-tools/:id/run
GET /features
# groups
POST/GET /groups GET/PATCH/DELETE /groups/:id
GET/PUT /groups/:id/tools
# agents
POST/GET /agents GET/DELETE /agents/:id POST /agents/:id/rotate-key
# schedules
POST/GET /groups/:id/schedules DELETE /schedules/:id
POST /schedules/:id/run GET /schedules/:id/runs
# secrets (metadata only; value/ciphertext is NEVER returned)
POST/GET /secrets DELETE /secrets/:id
# observability
GET /logs (?groupId&agentId&toolName&status&limit) GET /metrics
GET /agents/:id/inspect POST /agents/:id/invokePOST /a/mcp — agent-wide endpoint: union of tools across the agent's groups
POST /g/:groupId/mcp — Streamable HTTP endpoint (Authorization: Bearer <agent-key>)SSE 传输 — 计划中。
从 Claude / ChatGPT（网页版）连接： 带截图的分步指南 — docs/connect.md。
一个代码体为 Python 的工具。在复合引擎无法满足需求时很有用：循环、算术、解析、将多次调用折叠成一个表格。
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（{"id": "x", "python": "..."}）。
结果是你赋值给 output 的任何内容。如果脚本定义了 main，则调用 main(args)（同步或异步）。两者都没有 → 显式错误，永远不会静默返回空结果。
顶层的 return 是 Python 的 SyntaxError，会终止整个脚本 — 赋值给 output，或将逻辑包装在 def main(args) 中。
print() 会被捕获并显示在工具编辑器中。
沙盒。 Pyodide（CPython → WASM）在工作线程中：无网络，无文件系统，无 process。Node 的网络模块在 Pyodide 加载之前就在工作线程中被阻止，因此 Python 套接字也会失败 — 脚本的唯一出路是 call(...)，它通过正常的工具运行时（认证、SSRF 防护、调用日志）。失控的脚本通过终止工作线程来杀死。
成本。 每个嵌套级别一个工作线程，延迟启动并保持热状态：启动后首次运行 ≈ 1s，后续运行 ≈ 10ms。同一级别的运行是串行的，因此长时间运行的脚本会延迟其他 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）。
路径 | 用途 |
| Node 服务（Fastify + MCP SDK + Drizzle/Postgres）— 控制 API + 网关 |
| MCP 代理 · OpenAPI→工具 · HTTP 连接器 |
| 复合引擎（意图工具） |
|
|
| 组的虚拟 MCP 服务器 + 代理认证 |
| node-cron 注册表 + JobRun + 自定时任务 |
| 保险库（AES-256-GCM）+ |
| REST 端点 |
| Drizzle 模式 + pg 客户端（Postgres） |
| Web UI（Vite + React）— 源 / 工具 / V-MCP / 代理 / 密钥 / 日志 |
开发详情 — DEVELOPMENT.md。
密钥在静态时加密（AES-256-GCM）；代理/配置只能看到 ${secret.NAME} 占位符，值在运行时替换。
代理只能获得其组的工具集；每次调用都通过工具集进行门控。
API 密钥以 sha256 哈希存储，令牌仅显示一次。
一个上游的故障不会导致端点崩溃（运行时中的故障隔离）。
迭代构建，模块化。以下所有内容均已实现并正常工作。
✅ 连接器 — 代理现有 MCP 服务器，从 OpenAPI 3.x 导入 REST API（自有解析器 → 工具），或连接具有显式端点的 HTTP 服务。
✅ 工具注册表与策划 — 导入工具、重命名、编辑描述、切换可见性、每个所有者唯一名称。
✅ 复合引擎 — 按顺序运行多个调用的意图工具；条件 when；模板（$.input.*、$.steps.ID.text）；输出模板；每步跟踪用于调优。
✅ 共享运行时（invokeTool）— 一个调度器用于网关、复合工具和调度器；原生→连接器、复合工具→递归（深度限制）；故障隔离（坏的上游永远不会使调用者崩溃）。
✅ 组 = 虚拟 MCP — 将策划的工具捆绑到单个 MCP 端点 /g/:groupId/mcp（Streamable HTTP）。
✅ 代理 — 消费者身份，带有一个 API 密钥（sha256 哈希，仅显示一次）+ 密钥轮换。
✅ 代理 ↔ V-MCP 授权（M2M） — 按组授予/撤销访问权限；一个代理可以访问多个组端点；密钥仅对已授权的组有效。
✅ 调度器 — cron注册表 (node-cron), JobRun日志, 立即运行, 启动时加载。
✅ 通过MCP的自我调度 — 内置 schedule_task / list_schedules / cancel_schedule 工具在一个组内；连接的智能体自行调度。
✅ 保险库 — 凭证静态加密 (AES-256-GCM)；通过 ${secret.NAME} 在运行时注入；智能体/配置永远看不到值。
✅ 源级机密 — 同一名称可在每个源中存在；作用域覆盖全局。
✅ 静态认证 — Bearer/API密钥/自定义标头, Basic (用户名/密码)。
✅ 动态令牌流 — oauth2_client_credentials, token_request (登录→JSON路径), oauth2_refresh (缓存+自动刷新)。
✅ 用户OAuth — oauth2_authorization_code (Connect流) 和 MCP原生OAuth (mcp_oauth: SDK发现 + DCR + PKCE + 刷新，附带可选的预注册 clientId)。
✅ 认证 — 邮箱/密码 (scrypt) + HS256会话JWT；注册/登录/我。
✅ 多用户隔离 — 每个资源归用户所有；所有路由按所有者限定范围；工具仅在所有者命名空间内解析。无跨账户访问。
✅ 调用日志 — 谁/哪个工具/状态/持续时间/每次调用的令牌估算。
✅ 指标 — 总量 + 按工具 + 按智能体。
✅ 检查器与测试调用 — 查看智能体在每个授权的V-MCP中看到的内容；运行任何工具以查看原始响应。
✅ 认证 — 登录/注册, 令牌门控, 注销。
✅ 表单⟷JSON构建器 用于源和组合体 (编辑表单或原始JSON，双向)。
✅ 源向导中的内联机密 (作用域限定于该源)。
✅ 分组、可折叠、可搜索 的工具选择器与注册表 (可扩展至大型导入API)。
✅ 每个V-MCP的连接片段 (claude mcp add …, curl) 带复制按钮。
✅ 标签页: 源 · 工具 · V-MCP · 智能体 · 机密 · 日志。
✅ Postgres 通过 Drizzle (迁移在启动时自动应用)。
✅ Docker Compose 用于本地Postgres + Makefile (make setup / make dev / make db-*)。
✅ .env 加载，生成的开发机密。
⬜ 组织/项目层 (团队，共享)。
⬜ 网关上的SSE传输 (目前仅Streamable HTTP)。
⬜ 热重载 tools/changed 通知。
⬜ 工具集的OpenAPI端点；追踪。
对 /auth (密码暴力破解)、网关以及每个智能体的配额进行速率限制。
使调度器多副本安全 (Postgres咨询锁或专用工作进程) — 目前内存中的cron在N个实例上触发N次。
将迁移移至单独的部署步骤 (它们在每个实例启动时运行 → 与多个副本竞争)。
JWT撤销 — 短寿命访问 + 刷新令牌 (泄露的7天令牌无法失效；注销仅本地有效)。
机密管理 — KMS + 轮换 VAULT_KEY / JWT_SECRET；收紧CORS (默认 *)；记录TLS反向代理。
为生产环境提供Web UI (构建并发布 dist 在CDN/代理后；目前仅Vite开发)。
列表端点分页 (工具，日志)。
调度器重试/退避/告警。
OpenAPI解析器 — 处理复杂规范 (allOf, 深层 $ref)。
密码重置/邮箱验证；用户审计日志。
打包为 OCI镜像 (ghcr.io/comind-pro/comind-mcp) 并列入
官方MCP注册表 (registry.modelcontextprotocol.io) — 下游目录 (PulseMCP, Smithery, Docker Hub, …) 消费的权威来源。
元数据位于 server.json 中，在GitHub验证的命名空间 io.github.comind-pro/comind-mcp 下。
运行镜像 (零基础设施，嵌入式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发布是自动化的 — 推送版本标签，CI (release.yml)
构建并推送镜像到GHCR，然后通过GitHub OIDC (无需令牌) 将 server.json 发布到注册表:
git tag v0.2.0 && git push origin v0.2.0注意: ComindMCP 是一个多租户 网关 (HTTP MCP 位于
/g/:slug/mcp，智能体密钥认证)， 不是单个stdio服务器 — 注册表客户端自行部署它并连接自己的智能体。
comind-mcp 是开源的 (MIT) 欢迎贡献 — 错误报告、功能、文档、测试。
Fork 并从 main 分支 (feat/..., fix/...)。
本地设置 — 见 DEVELOPMENT.md。简而言之: corepack enable && pnpm install, 然后 pnpm dev。
在打开PR之前: pnpm typecheck 和 pnpm -r test 必须通过。
使用 Conventional Commits 编写消息 (feat:, fix:, docs:, chore:)。
向 comind-pro/comind-mcp 提交PR，附上清晰描述；链接相关issue。
有问题或想法？请打开 issue。详情见 CONTRIBUTING.md。
MIT © comind — 开源，可自由使用、修改和分发，包括商业用途。
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.