fix_bpa

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. It discloses critical behavior: dryRun defaults to true and lists what would change without modifying anything; dryRun=false applies changes; rules without a safe automatic fix are refused with guidance. It also clarifies scope semantics (all vs one object). However, it does not mention side effects such as persistence, whether changes are reversible, or what outputs/returns are produced after applying.

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 and appropriately structured: it front-loads the core purpose, then covers scoping semantics, dryRun behavior, and refusal cases in three subsequent sentences. Every sentence provides necessary information and there is no filler or redundancy.

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?

Given the tool's moderate complexity (scoping, dryRun, refusal cases) and the absence of both annotations and an output schema, the description covers the key decision points: what happens with no objectName vs objectName, how to preview vs apply, and which rules are not supported. It falls slightly short by not describing the expected output format or what happens when there are no matching objects or violations, but the described behavior is sufficient for an agent to select and invoke 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 input schema already documents ruleId, sessionId, dryRun, and objectName with 75% coverage. The description adds meaningful semantics beyond the schema: it explains that the autofix sets the exact TOM property named by the rule (with examples), and clarifies the difference between omitting objectName (fix all matching objects) and providing it (fix only that one). This enriches the dryRun and objectName parameters but leaves sessionId entirely unexplained.

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 opens with a specific verb and resource: 'Apply a BPA rule's autofix', and immediately clarifies what the tool actually does: sets the precise TOM property named by the rule, with concrete examples. It also clearly distinguishes from sibling tools like run_bpa, list_bpa_rules, and import_bpa_ruleset by focusing on the autofix application behavior.

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 gives clear usage context: it explains the difference between fixing all matching objects (no objectName) versus a single object (with objectName), and provides the dryRun=true (preview) vs dryRun=false (apply) workflow. It also states explicit exclusions: rules with no safe automatic fix are refused with guidance. However, it does not name alternative sibling tools (e.g., run_bpa) for when a user only wants to detect issues rather than fix them.

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