write_guard

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

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds almost nothing behavioral beyond restating the dry_run/enforce enum, already present in the schema — no mention of persistence of added regions, session scope, or what audit returns.

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?

Front-loaded with the purpose, then a compact action/parameter map. It is efficient, though the telegraphic notation trades clarity for brevity and could be slightly more readable.

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?

For a 6-parameter configuration tool with full schema coverage and no output schema, the definition covers the action-parameter relationship but omits return-value expectations, whether policy changes persist, and how session scoping interacts with the default target. Adequate but with clear gaps.

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 coverage is 100%, so the baseline is 3, but the description meaningfully maps parameters to actions (policy takes mode/add_allow/add_protected; audit takes limit), which the oneOf schema does not disambiguate. This is genuine added value beyond the structured data.

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?

The description states 'Memory-write guardrail', which conveys the general domain, and it names two operations (policy, audit). However, it never says in plain language what 'policy' or 'audit' actually do — the purpose is expressed only through compressed notation, and it does not differentiate this tool from siblings like write_memory or configure_debug_freeze.

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?

There is no guidance on when to choose policy vs audit, no prerequisites, and no mention of alternative tools. The action list implies two modes of operation but leaves all selection logic to inference.

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