Loading ToolBench
MCP server that exposes a Command Center workspace to agents. Thin stdio bridge that exposes the Command Center REST API as MCP tools. Agents (Hermes, OpenClaw, Claude Code, Claude Desktop, Cursor, etc.) connect over stdio and can read the workspace, update items, promote, and run cleanup.
Command Center MCP exposes 10 tools with clear verb-noun naming (get_, search_, update_, connect_, promote_, capture_, scan_, apply_). All tools have descriptions (avg 150 chars, within baseline 34-392). Input schemas are present and use Zod validation with type constraints. However, parameter descriptions are sparse or missing entirely, most params lack actionable guidance on format, range, or valid values. Output schemas are not documented; responses are JSON-stringified without field-level documentation. Error handling is minimal (generic fetch errors). No tool annotations (readOnlyHint/destructiveHint). Batch operations (update_items, promote_items) are well-designed, but single-item tools like connect_items lack idempotency guidance.
Apply a cleanup action: archive a duplicate group, demote heartbeat items, or bulk archive/reference/delete. Use the report from scan_queue_noise to decide what to run.
Create a new item in the workspace. Typically used by capture-source integrations (browser extension, CLI, email-in), not during agent triage.
Create a connection between two items.
Remove a connection between two items.
Just the items currently flagged as needing review. Convenience wrapper over get_workspace.attention.
Full workspace snapshot: stats, recent items, attention queue, duplicate groups, oldest open, low-connection backlog, and existing connections. Call this first in every triage pass.
Parameter descriptions are minimal or absent. Most params (e.g., 'limit', 'status', 'action', 'relationship_type') lack guidance on format, valid values, or constraints. LLMs cannot infer whether 'status' accepts 'open|closed|pending' or free-form text.
Output schemas are not documented. Tools return JSON-stringified responses via textResult() but do not declare what fields the response contains. Agents cannot plan downstream calls or extract specific data without trial-and-error.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Destructive tools like apply_queue_cleanup (action='delete') and promote_items lack explicit warnings. LLMs cannot distinguish safe reads from irreversible writes without annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Promote items to the configured promotion target (webhook by default). Sets status=promoted and pushes the item externally. Only use when the item has a clear owner and next action.
Report of duplicate groups, stale repeat groups, heartbeat clutter, stale items, and orphaned items. Run during weekly consolidation, not daily triage.
Search items by text query or metadata filters (status, category, focus_area).
Batch state/metadata updates. Prefer this over per-item calls — the API handles the whole batch atomically.
Error handling is generic. fetch() errors are caught and re-thrown as plain Error objects with no recovery guidance. LLMs receive '404: not found' with no hint to try search_items or alternative actions.
Enum constraints are missing. 'status' in search_items, 'action' in apply_queue_cleanup, and 'relationship_type' in connect_items accept free-form strings. No enum declaration prevents LLMs from discovering valid options.