Loading ToolBench
Model Context Protocol server for the cma compound practice loop. Subprocess wrapper around the canonical bash cma binary; methodology-agnostic substrate; three-section payload (analysis + agent_guidance + provenance) on every response.
cma-mcp defines 7 tools with clear domain purpose (failure/decision/rejection capture for compound practice loops). All tools have descriptions (10-200+ chars) and input schemas with typed parameters. However, schemas lack formal JSON Schema structure (no explicit 'type', 'required', 'properties' blocks visible in source), parameter descriptions are present but terse (avg ~40 chars), and output schemas are entirely undocumented. Error handling is minimal, no recovery guidance or actionable error messages. Tool naming follows verb_noun convention (cma_*) but is domain-specific jargon that may confuse LLMs unfamiliar with 'cma' methodology. No tool annotations (readOnlyHint, destructiveHint) despite clear read/write distinctions.
Capture an architectural or strategic choice. Format the description as 'TOPIC: choice (rationale)'. The --applies-when predicate is matched against context at action time: when surface or file context contains any keyword in applies-when, the decision surfaces alongside other captures.
Promote a learning, retire a learning, or preview accumulated patterns.
Capture a failure. The description is required; remaining flags are optional. Texture fields (excerpt, intended, corrected) preserve the conditions of the failure so future surfacing can match by situation, not just keywords.
Capture a moment where a surfaced warning prevented a recurrence.
Capture an eliminated option. Format the description as 'OPTION: reason'.
Evidence dashboard. Default mode shows summary; flags select views. The --evidence view composes preventions and leaks into a single prevention-rate signal over a trailing window (default 30 days). With --json, emits a machine-readable record instead of prose. The --recurrence view defaults to all-time; --window N scopes it to the trailing window.
Input schemas lack formal JSON Schema structure. Parameters are documented in descriptions but no explicit 'type', 'required', 'properties', or 'additionalProperties' blocks visible. LLMs cannot validate inputs against machine-readable constraints.
Output schemas completely undocumented. No specification of return types, field names, or structure for any tool. LLMs cannot plan downstream calls or extract required data.
No error handling guidance. Tools do not document what errors are possible, whether they are retryable, or what the LLM should do next. Bare error codes or exceptions provide no recovery path.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Bring relevant prior captures into view for the current context.
Tool names use domain-specific prefix 'cma_' without clear verb-noun structure. 'cma_surface' and 'cma_distill' are opaque to LLMs unfamiliar with compound practice methodology. Consider 'capture_failure', 'retrieve_captures', 'promote_learning' for clarity.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). cma_surface and cma_stats are clearly read-only; cma_miss, cma_decision, cma_reject, cma_prevented, cma_distill are write operations. Annotations enable safer agent planning.