approve_rule

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

With no annotations, the description carries the full burden. It discloses the key side-effect (rule activates and starts inferring facts immediately) and an important behavioral rule (cannot approve own rules, must be human-approved). This is strong transparency for a mutation tool, though it could mention additional details like reversibility or error conditions.

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?

The description is concise, with no filler. The first sentence states the action and consequence; the second paragraph delivers the essential human-in-the-loop instructions. Every sentence contributes critical guidance.

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 tool with significant operational constraints, the description is quite complete. It covers purpose, side-effects, and the approval workflow. It does not explain error handling or what happens if the rule is not pending, but given the simple parameter set and no output schema, the description provides sufficient context to use the tool correctly.

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?

The schema is 100% covered with 'ID of the rule to approve'. The description adds context about the rule being pending and displayed via suggest_rule, which enriches the meaning of rule_id. However, it doesn't add specific syntax or format details, so the baseline of 3 for high schema coverage is appropriate.

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 clearly states the tool's purpose: approve a pending rule and activate it in the inference engine. It uses a specific verb ('approve') and resource ('rule'), and the mention of immediate fact inference distinguishes it from related tools like reject_rule or suggest_rule.

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 description provides explicit usage guidelines: do not call automatically, wait for user input, cannot approve own rules, display the rule via suggest_rule, and only proceed after user explicitly says 'Approved' or 'Yes'. It also implicitly contrasts with reject_rule for rejection. This fully satisfies the when/when-not/alternatives criterion.

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