Skip to main content
Glama
metabolism-tools

workspace-metabolism

by metabolism-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

wm_audit

Run a read-only workspace audit and get a JSON report of every covered path, its grade, cleanup state, and anomalies. Summarizes sensitive files by default; never modifies files.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dupesNoWhen true, additionally scan for possible duplicate files (slower).
detailNosummary (default) returns sensitive files as counts plus one group per dependency tree and lists workspace-owned files individually; full returns every sensitive entry, as earlier versions did. Nothing is dropped in either mode — the full list is always written to the audit report file (report_path).summary

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.1
    • addedInput schema / properties / detail
      Added value: +{
+  "default": "summary",
+  "description": "summary (default) returns sensitive files as counts plus one group per dependency tree and lists workspace-owned files individually; full returns every sensitive entry, as earlier versions did. Nothing is dropped in either mode — the full list is always written to the audit report file (report_path).",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers: it states the operation is read-only, explains the summary vs. full detail behavior, notes that sensitive files are summarized by default, clarifies that nothing is dropped in either mode, and specifies the failure behavior when no policy file exists. This is rich behavioral context beyond what any schema could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place: purpose, output format, usage timing, summary behavior, detail parameter semantics, and safety guarantee. It is front-loaded with the core purpose and ends with the most important safety and failure behaviors. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only audit tool with 2 optional parameters and no output schema, the description is complete. It covers what the tool returns, when to use it, how the parameters affect behavior, what happens in edge cases (no policy file), and the safety profile. An agent has everything needed to invoke it correctly without opening the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the practical effect of the detail parameter ('a 'nothing is due' answer stays small') and by clarifying that the full list is always written to report_path regardless of mode. It also explains the dupes parameter's cost ('slower'). This goes beyond the schema's descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Run a read-only workspace audit') and resource ('the metabolism policy'), and clearly distinguishes itself from siblings by emphasizing it returns a report and never modifies files. It also names the exact output (JSON report with paths, grades G1-G4, cleanup state, anomalies), which makes the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use it: 'at the start of a session' and 'before planning any cleanup.' It also contrasts with the sibling wm_clean by stating it never moves or modifies files, which helps an agent choose between audit and cleanup tools. This is explicit when-to-use guidance with an implicit alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools