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

Goes well beyond the annotations by disclosing the key consequence: the current recipe is dropped, the AI writes a new one, and it needs re-approval before the monitor runs again. This tells the agent what gets destroyed and what the follow-up workflow is. It could still note permission or side-effect scope, keeping it at 4 rather than 5.

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?

Two tight sentences with no waste: the first front-loads what changes, the second immediately conveys the destructive consequence. Every sentence earns its place.

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 destructive, non-idempotent mutation with no output schema, the description supplies the essential behavioral consequence and the re-approval requirement. Remaining gaps are the undocumented boolean params, but the core invocation context is present.

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 67%, and the description names goal, page, name and mode, loosely mapping to url, goal, name, and the boolean mode-like params. However, checkId, interactive and authenticated are not clarified in either schema or description, so the description adds only marginal meaning. Baseline 3 for mid coverage.

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 (change/edit) and resource (custom monitor) plus the fields being changed (goal, page, name, mode), which clearly distinguishes it from add_custom_check and approve_custom_check. It does not explicitly name the sibling it differs from, so it falls short of a 5.

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?

The phrasing implies this is the edit path for an existing custom monitor, but there is no explicit when-to-use guidance, no prerequisites, and no comparison against alternatives like reauthor_custom_check or update_check. Usage is implied rather than stated.

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