リポジトリ: https://github.com/comind-pro/comind-mcp
MCP ゲートウェイ — さまざまな MCP サーバーや REST API を接続し、ツールをキュレーション・組み合わせてグループ（各グループは単一エンドポイントを持つ独立した仮想 MCP サーバー）に整理し、エージェントに提供できます。エージェントは割り当てられた狭いツールセットのみを認識し、MCP 経由で独自の cron をスケジュールできます。
セルフホスト: 単一の 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、マイグレーション）が変更なしで動作します — 外部 DB プロセスは不要です。永続性: file: ディレクトリは実際の Postgres データディレクトリです。ボリュームとしてマウント（例: /data）することで、リリース間でデータを保持できます。マイグレーションは追加的かつ冪等なので、アップグレードで既存データが消えることはありません。組み込みモードはシングルノードです（マルチインスタンス不可 — ライターは1つ）。
# 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> を設定。クライアントはグループのツールセット（+ セルフ cron ツール）のみを認識します。
ログ → 呼び出し、メトリクス、エラー。
用語 | 説明 |
ソース | 上流: 別の MCP サーバー（プロキシ）、REST API（OpenAPI 3.x → ツール）、または明示的なエンドポイントを持つ HTTP サービス |
ツール | 単一の呼び出し。 |
コンポジット | 複数の呼び出しを決定的に実行し、単一の結果を組み立てる（出力テンプレート、 |
Python ツール | WASM サンドボックスで実行される Python コード — ネットワークなし、ファイルシステムなし。 |
グループ | 仮想 MCP サーバー: キュレーションされたツールセットを単一エンドポイント |
エージェント | API キーでグループにバインドされたコンシューマ。グループのツールセットのみを認識 |
セルフ cron | グループ内の 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（Web）から接続: スクリーンショット付きのステップバイステップガイド — docs/connect.md。
本体が Python であるツール。コンポジットエンジンでは対応できない場合に便利: ループ、算術、パース、複数の呼び出しを1つのテーブルにまとめるなど。
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 ガード、呼び出しログ）を経由します。暴走したスクリプトはワーカーを終了させることで強制終了されます。
コスト。 ネストレベルごとに1つのワーカーが遅延起動され、ウォーム状態を維持: 起動後の初回実行 ≈ 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）。
パス | 目的 |
| Node サービス（Fastify + MCP SDK + Drizzle/Postgres） — コントロール API + ゲートウェイ |
| MCP プロキシ · OpenAPI→ツール · HTTP コネクタ |
| コンポジットエンジン（インテントツール） |
|
|
| グループの仮想 MCP サーバー + エージェント認証 |
| node-cron レジストリ + JobRun + セルフ cron |
| ボールト（AES-256-GCM）+ |
| REST エンドポイント |
| Drizzle スキーマ + pg クライアント（Postgres） |
| Web UI（Vite + React） — ソース / ツール / V-MCP / エージェント / シークレット / ログ |
開発の詳細 — DEVELOPMENT.md。
シークレットは保存時に暗号化（AES-256-GCM）; エージェント/設定は ${secret.NAME} プレースホルダーのみを認識し、値は実行時に置換されます。
エージェントは自身のグループのツールセットのみを取得; 呼び出しはリクエストごとにツールセットで制御されます。
API キーは sha256 ハッシュとして保存され、トークンは一度だけ表示されます。
1つの上流の障害がエンドポイント全体をダウンさせることはありません（ランタイムの障害分離）。
モジュールごとに反復的に構築されています。以下はすべて実装済みで動作しています。
✅ コネクタ — 既存の MCP サーバーのプロキシ、OpenAPI 3.x からの REST API インポート（独自パーサー → ツール）、または明示的なエンドポイントを持つ HTTP サービスの配線。
✅ ツールレジストリとキュレーション — ツールのインポート、リネーム、説明の編集、可視性の切り替え、所有者ごとの一意の名前。
✅ コンポジットエンジン — 複数の呼び出しを順次実行するインテントツール; 条件付き when; テンプレート（$.input.*、$.steps.ID.text）; 出力テンプレート; ステップごとのトレースで調整可能。
✅ 共有ランタイム（invokeTool） — ゲートウェイ、コンポジット、スケジューラーに共通のディスパッチャー; ネイティブ→コネクタ、コンポジット→再帰（深さ制限）; 障害分離（悪い上流が呼び出し元をクラッシュさせることはありません）。
✅ グループ = 仮想 MCP — キュレーションされたツールを単一の MCP エンドポイント /g/:groupId/mcp（Streamable HTTP）にバンドル。
✅ エージェント — 1つの API キー（sha256 ハッシュ、一度だけ表示）を持つコンシューマ ID + キーローテーション。
✅ エージェント ↔ V-MCP 許可（M2M） — グループごとにアクセスを許可/取り消し; 1つのエージェントが複数のグループエンドポイントにアクセス可能; キーは許可されたグループに対してのみ機能します。
✅ スケジューラ — cronレジストリ (node-cron)、JobRunログ、即時実行、起動時にロード。
✅ MCP経由のセルフcron — グループ内に組み込みの schedule_task / list_schedules / cancel_schedule ツール。接続されたエージェントが自身をスケジュール。
✅ Vault — 保存時に暗号化された認証情報 (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 via 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など）が消費する正規のソース。メタデータはGitHub検証済み名前空間 io.github.comind-pro/comind-mcp の下の server.json に存在。
イメージを実行（ゼロインフラ、組み込み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 at
/g/:slug/mcp、エージェントキー認証）であり、単一のstdioサーバーではありません — レジストリクライアントはそれを自己デプロイし、自身のエージェントを接続します。
comind-mcpはオープンソース（MIT）であり、コントリビューションを歓迎します — バグ報告、機能追加、ドキュメント、テスト。
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.