Loading ToolBench
MCP server and CLI for policy-driven file governance in AI workspaces: audit, reversible cleanup, rollback, and verification.
workspace-metabolism provides well-documented tools with comprehensive descriptions and clear parameter schemas. Most tools have good naming (verb_noun pattern: wm_audit, wm_clean, wm_rollback) and detailed descriptions (180-300 chars on average). Input schemas are properly structured with types and descriptions. However, OUTPUT schemas are not documented, responses are described in prose but lack formal JSON Schema definitions. Some parameter descriptions could be more constraint-explicit. Error handling guidance is embedded in descriptions but not formalized in error response patterns. Tool composition is excellent (single responsibility, clear chaining via run_id and path parameters), but no tool annotations (readOnlyHint/destructiveHint/idempotentHint) are present despite clear risk levels documented in the tool registry.
Run a read-only workspace audit and return the complete report as JSON: every path the policy covers, its grade (G1-G4), its cleanup state, and any anomalies. Use this at the start of a session to see what the metabolism policy says about the workspace, or before planning any cleanup. Sensitive files are summarized by default — dependency trees collapsed into counted directory groups, workspace-owned files listed individually — so a 'nothing is due' answer stays small; pass detail='full' for every entry. Never moves or modifies any files; if no policy file exists it reports that instead of failing.
Plan or execute a policy-driven cleanup. By default it is a dry-run: returns the exact plan (what would be moved to the recycle area, with per-file SHA-256 hashes) and changes nothing. Pass execute=true to apply the plan: items are moved to a recycle area, never deleted by pattern, and every action lands in the hash-chained journal so rollback is possible. Use it when the workspace has accumulated policy-expired byproducts. Do NOT set execute=true without first running a dry-run and confirming the plan; G3 execution additionally requires approve=true and an approver.
Check the exact SQLite resource registered by resource_id in the policy. Read-only: returns table names, never creates databases or tables, repairs, deletes, searches for substitutes, or accepts SQL. Missing/empty databases and missing required tables fail. Success checks path/schema only, not data freshness or identity.
Return the 'nutrition label' for one path: the grade the policy assigns (G1-G4), why it is graded that way, and what cleanup would do to it. Use this when you or the user ask why a specific file or directory is (or is not) cleanup-worthy. Read-only; fails with a clear message if the path is outside the workspace or the policy is missing.
Output schemas not documented. Tool descriptions state what is returned ('return it with the per-component breakdown as JSON', 'return the exact plan') but no formal JSON Schema is provided for responses. LLMs cannot reliably parse or chain on undocumented output structures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels in the tool registry. wm_clean and wm_rollback are marked REVERSIBLE; wm_init and wm_db_check are marked WRITE. These annotations guide agent reasoning about safety, idempotency, and retry logic.
wm_govern description is sparse (70 chars). It states the action but does not explain WHEN to call it vs wm_audit/wm_clean, what policy violations it checks, or how it differs from a dry-run clean. 'Check whether an AI action is allowed' needs context: is this a permission check, a policy audit, or a dry-run preview?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
Check whether an AI action is allowed by the workspace policy without performing it. Unknown actions are denied by default. Write actions can require a preview, and sensitive actions can require a named human approver. The decision is recorded in the hash-chained journal.
Compute the workspace health score (0-100) and return it with the per-component breakdown (coverage, compliance, cleanliness) as JSON. Use this to quantify in one number how well the workspace follows its policy, e.g. for CI gates or session-end reporting. Read-only; requires a policy file — if none exists it returns an error telling you to run 'wm init'.
Scaffold the metabolism.json policy file for this workspace (like git init): scans the workspace and generates a policy that grades every directory G1-G4 with safe defaults — source, docs, tests, secrets, dotfiles and version control are never auto-cleaned. Use this once, when no policy file exists, before the first audit or clean; after it succeeds, wm_audit and wm_clean can operate. Fails without writing anything if a policy already exists and force is not set.
Restore the items of a previous wm_clean run from the recycle area back to their original locations. Every item is verified against its recorded SHA-256 hashes first; items that fail the integrity check, are missing, or would overwrite an existing file are skipped with a reason. Use this to undo a cleanup you just executed, passing the run id printed by wm_clean. Dry-run by default; set execute=true to actually restore. Fails with a clear message if the run id is unknown.
Verify the integrity of the audit trail: check that the hash-chained journal has not been tampered with and that run manifests are consistent, returning pass/fail per check with details as JSON. Use this before trusting any previous clean/rollback history, or after suspecting manual edits to the journal. Read-only.
wm_govern parameters 'paths' and 'approver' lack detailed descriptions. 'paths' is an array but no description explains whether it accepts strings (relative paths?), what format (glob? exact?), or whether it must be relative to workspace root.
No pagination guidance. wm_audit and wm_health return unbounded JSON structures. If audit reports on thousands of paths, the response could exhaust context. No limit parameter or next_cursor is offered.
Error recovery guidance missing. Descriptions state prerequisites ('requires a policy file, if none exists it returns an error telling you to run wm init') but do not formalize error codes or recovery paths. What errors can wm_audit return? How should the agent respond to each?