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

Annotations already mark the tool read-only and non-destructive, but the description adds substantial behavioral detail: re-hashing every file, the exact mismatch conditions (changed, missing, added), the consequence of a mismatch, and remediation via re-fetching from boosthis_get_integration_kit. It also clarifies the tool's execution environment and its read access to project files.

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 front-loaded with the core purpose and status semantics, then adds a practical implication and environment caveat. Every sentence carries useful information without filler or repetition, and the length is appropriate for the complexity of the tool.

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 single-optional-parameter, read-only verification tool with no output schema, the description covers what the tool does, what the outcomes mean, why those outcomes matter, how to remediate, and where the tool can be executed. No critical information needed to call it correctly is missing.

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 has 100% description coverage for the single optional 'path' parameter, including its default behavior and example value. The description does not need to add parameter-level detail because the schema already fully documents it, so the baseline 3 applies.

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: 're-hashes every vendored Boosthis-owned file against the shipped boosthis-kit-manifest.json'. It clearly defines the tool's output states ('ok' and 'mismatch') and distinguishes this integrity check from sibling tools by discussing the local vs hosted server 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 context for use: it is a tamper-evidence check, and it explains that a mismatch can disable the kit at the next entitlement check-in. It also specifies that this tool works best from a local stdio server because the hosted server cannot see project files, but it does not explicitly enumerate when-not-to-use conditions relative to siblings like verify_kit_install.

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