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

Annotations already say read-only and non-destructive, but the description adds substantial behavioral context: it reports each question separately, includes evidence windows, explicitly says it will say when evidence is insufficient instead of guessing, and states there is no combined score or personal judgement. It also discloses that Boosthis never sees code, only app-reported measurements. This goes well beyond what the annotations provide and does not contradict them.

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 first sentence fronts the core purpose, and subsequent sentences earn their place by explaining the answer granularity, evidence policy, and privacy boundary. It is somewhat long and flowing, but every clause contributes useful behavioral information rather than filler.

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?

There is no output schema, so the description carries the burden of explaining what an agent will receive: five separate answers, each with numbers and a window, with explicit handling of insufficient evidence and future answerability. For a single-optional-parameter read-only tool, this is complete enough to invoke 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?

There is only one parameter and schema description coverage is 100%, so the schema already fully explains `runtime` including examples and its omission behavior. The description restates the same runtime semantics without adding materially new meaning, matching the baseline for high schema 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?

The description opens with a specific verb and resource: finding out how the last release held up from the running app after shipping. It then enumerates the five separate questions it answers, which clearly distinguishes it from generic release or trend tools. This prevents confusion with siblings like boosthis_trend or boosthis_promises.

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 clearly says to use this tool to check post-release performance and stability, and gives explicit runtime parameter guidance: pass a runtime to choose one, or omit it to use the most recently reported one. It does not name sibling alternatives or state when not to use it, so it stops short of the highest bar.

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