Initializes audit documentation by creating AUDIT.md only when missing, preserving existing files and making repeated runs safe.
Initialize AUDIT.md if missing (idempotent).
| Name | Required | Description | Default |
|---|---|---|---|
| project_root | Yes |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the key behavioral trait — idempotency, so no overwrite risk — but says nothing about what the created file contains, whether parent directories are created, or what the call returns on first vs. subsequent invocation.
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?
One short sentence, front-loaded with the action and the artifact. It is efficient but arguably too terse — the parenthetical is the only supporting detail and no room is given to scope or path semantics.
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?
No annotations, no output schema, and zero parameter documentation leave real gaps: the agent cannot determine what project_root expects, where the file lands, or what a successful response looks like. For a filesystem-mutating init tool, more disclosure is warranted.
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?
Schema description coverage is 0%, so the single parameter project_root has no documented meaning anywhere. The description does not clarify whether it is an absolute path, a repo root, or a project identifier, nor how it relates to the AUDIT.md location.
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?
States a specific verb (Initialize) and a specific artifact (AUDIT.md), with a condition (if missing). It is distinguishable from siblings like init_plan and init_agents by the target file, though it never says what an AUDIT.md is or contains.
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?
'if missing' implies the trigger condition and 'idempotent' signals it is safe to call when unsure. However, no alternatives or prerequisites are named — an agent cannot tell whether this should precede or follow init_plan/init_task, or whether it belongs in a bootstrap sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.