Boosthis

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered structurally. The description adds genuine behavioral context: outcome values are kept/broken/cant_tell, cant_tell means thin evidence rather than approval, and no assistant score is exposed or derivable. It also reinforces 'Read-only,' which is redundant but consistent.

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 not bloated, but it is cryptic and domain-specific, with the core action buried behind 'What happened after the changes Boosthis witnessed here.' It front-loads the outcome theme reasonably, yet the sentence structure and unusual vocabulary reduce immediate clarity.

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 no-parameter, read-only tool with no output schema, the description does explain the meaningful return vocabulary and cautions that cant_tell is not a clean bill of health and no score is available. It is fairly complete on output interpretation, though the lack of a plain action statement keeps it from being fully self-explanatory.

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 tool has zero parameters, so there are no parameter semantics for the description to clarify. Schema description coverage is 100%, and the baseline for a 0-param tool is 4.

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 gestures at a read operation over changes Boosthis has witnessed and describes their outcome labels, but it never plainly states the verb or resource, e.g. 'list AI change outcomes.' The phrasing 'What happened after the changes Boosthis witnessed here' is evocative but leaves an agent to infer that this returns per-change results.

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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative among siblings such as boosthis_record_change or boosthis_promises. The scope 'only those that passed through it' implies a boundary, but the description does not tell an agent when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is partly covered, and the description adds real value on top: it cannot mark anything fixed/muted/dismissed, returns no credentials, and reports the total match count so a trimmed list is not mistaken for the whole. It stops short of describing pagination mechanics or ordering.

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?

Three dense sentences, front-loaded with the resource and status vocabulary, with the count-honesty and read-only caveats following. Tight and non-repetitive, though the parenthetical glosses make it slightly denser than needed.

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?

With no output schema, the description takes on the return-shape burden and does so adequately (status set, muted flag, match count), plus it states the read-only constraint. Nothing critical is missing for a 4-parameter read-only list tool.

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 100%, so baseline is 3, but the description earns more by translating display labels (e.g. 'Closed by Boosthis', 'Returned (closed, then again)') into the raw status tokens the enum uses, and by noting each row's Muted indicator. It adds no meaning for limit or search beyond the schema.

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 resource (this account's Boosthis alerts) and enumerates the exact status values an agent will encounter, so the operation is unambiguous. It does not name or contrast with any sibling tool, so an agent must infer routing on its own.

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?

Usage is only implied: the description makes clear this is for inspecting alerts, but never says when to reach for it versus siblings like boosthis_what_should_i_look_at_next or boosthis_vigilance. No exclusions or alternative-selection conditions are given.

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

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

Goes well beyond the readOnlyHint annotation: it discloses the four-outcome answer space, that Boosthis chooses the comparison window and ignores one named in the sentence, and—unusually candid—that it only catches about one in six wrong claims and never catches vague ones. This is exactly the limitation context an agent needs to weigh the result.

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?

Front-loaded with the core purpose before qualifications, and each sentence carries information (outcomes, window rule, accuracy ceiling). The trailing 'Read-only' restates the readOnlyHint annotation and is the one piece of waste.

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?

With no output schema, the description compensates by enumerating the four verdict values, and both parameters are fully described in the schema. Accuracy limits, window behavior, and read-only status are all covered, leaving nothing an agent needs in order to call it 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?

Schema description coverage is 100%, so the 240-character limit, credential refusal, and the account_token AI-allowance cost are already documented. The description adds only the window-handling note, which reads more as tool behavior than as parameter guidance, 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?

States a precise verb+resource: it holds a proposed sentence against what the running app actually did, and enumerates the four exact verdicts it can return. The scope is unambiguous and clearly distinct from sibling checks like release_check or verify_kit_install.

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?

Usage is only implied ('a sentence an assistant is about to say'), i.e. call it before asserting a claim. The limitation notes ('catches only a minority of wrong claims', 'a vague claim is never caught') help the agent judge when the call is worthwhile, but no explicit when-not conditions or alternative tools are named.

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

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

Annotations cover only readOnlyHint and openWorldHint, so the description carries the rest, and it does: it details the full response shape (severity tiers, per-release changelogs), a fallback HTTP path for a withheld reply with auth (project key as bearer), and the authoritative-source caveat that a local stdio server reports its own container. These are meaningful behavioral disclosures beyond the annotations, though it omits rate-limit or error-handling specifics.

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 content is front-loaded with the core question, but it is a dense run-on listing of outputs, caveats, and a URL, packed with terminology an agent must parse. It is informative yet weakly structured for scanning.

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 no-output-schema read tool with full schema coverage, the description supplies the output vocabulary, the hosted-vs-local nuance, and the REST fallback, so nothing essential to invoking it appears missing. It stops short of covering error or rate-limit behavior.

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 100%, so the schema already documents runtime, repair_steps, and installed_version. The description adds little per-parameter meaning beyond echoing 'latest_version' and 'kit_download_url' as concepts, 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?

States a clear verb+resource (check for a newer kit for this project) plus explicit scope ('without fetching it'). It enumerates the concrete outputs (latest_version, update_available, comparison, changelog, severity, recommendation), which sharply distinguishes it from siblings like boosthis_release_check. It does not name that specific sibling, 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 'without fetching it' framing implies when to use this (pre-flight check) versus get_integration_kit (which downloads), but no alternative is named and no when-not condition is given. Usage is inferable rather than stated, which lands at a minimum-viable 3.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that: it discloses the equivalent plain-HTTPS endpoint and auth method (GET /api/connection-status, project key as bearer) and explicitly states it returns no credentials, which matters for a status tool. It stops short of describing rate limits or pagination.

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 purpose is front-loaded and the supplemental detail (HTTPS equivalent, credential note, interpretation nuance) is relevant. Some phrasing ('What Boosthis knows about...') is indirect and the interpretive sentence is slightly verbose, but nothing is wasted.

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?

With no output schema, the description carries the burden of describing returns, and it does so competently: runtime, state, last-heard time, and their meaning. The read-only and no-credentials facts round out the picture for a simple one-param tool.

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 100% and the single parameter (repair_steps) is fully documented there, so the baseline of 3 applies. The description never mentions repair_steps or what the repair text contains, adding no meaning beyond the schema.

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 states a specific resource (this account's installs) and enumerates what is reported: runtime, state, last-heard timestamp, and interpretation of that state. It clearly frames the tool as an 'is it working?' diagnostic, but it never names or distinguishes itself from closely related siblings like boosthis_verify_kit_install or boosthis_which_kits, so an agent must infer the boundary.

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?

Usage is implied by 'It answers "is it working?" without guessing' and the note about distinguishing registered-but-never-measured installs from genuinely quiet apps. However, there is no explicit when-to-use versus alternatives guidance, and no named sibling the agent should prefer for overlapping checks.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces that with 'Read-only.' It goes beyond annotations by disclosing that signatures are code-derived (never raw messages) and that no user value is exposed, plus the fallback note for missing credentials or no crashes. This adds valuable behavioral context beyond the safety flag.

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 a single dense sentence with a clear subject, then a follow-up on privacy and a note. It packs a lot of specifics without redundancy, though it could be slightly more streamlined. The front-loading of the main content is effective.

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 complexity (multiple fields, joins, fallback behavior) and the absence of an output schema, the description covers the return structure, ordering, privacy guarantees, and edge cases. It does not explicitly describe the exact JSON shape, but that is not required when no output schema exists. The description is sufficiently complete for an agent to understand what to expect.

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 covers both parameters (install_id and read_token) with full descriptions, so the schema already documents them. The description does not add parameter-specific guidance (e.g., where to find the token or how to format it), but since schema coverage is 100%, the baseline of 3 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 specifies a concrete resource ('crash classes this app recorded') and details the exact fields returned (error name, redacted top frame, occurrence bucket, relatedRules), along with the ordering ('newest first') and the join with the Stability summary. It is unmistakably a read-only crash information tool and clearly distinct from siblings like boosthis_full_stack_trace, even without naming them.

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?

No explicit when-to-use or when-not-to-use guidance is given. It describes what the tool returns, but it does not mention alternatives (e.g., full_stack_trace for deeper stack detail) or any conditions that would select this tool over others. 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and 'Read-only' merely restates that. The added value is the 'Each carries its limits; never a safety claim' caveat, which usefully tells the agent the findings are bounded observations rather than verdicts — genuine context beyond the structured fields, though it is vague about the nature of those limits.

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?

A single dense sentence plus two short fragments, with the content list front-loaded and no filler. The telegraphic, comma-heavy style is tight but slightly cryptic to parse.

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?

With no parameters, no output schema, and read-only annotations, the description does the necessary work of telling the agent what the return contains (six named finding categories) and how to read it (bounded, not a safety guarantee). It stops short of describing the result shape or how limits are surfaced per finding.

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 tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. No parameter meaning is missing or misleading.

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 states a specific resource and enumerates the concrete categories of findings (leaks, cookie flags, dev settings, turned-away traffic, build age, swallowed errors), and the capitalized 'OBSERVED' distinguishes evidence-based findings from speculation like crash_risk. However, it never names a sibling alternative, so the agent must infer the boundary from the list alone.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the many siblings. The only guidance-like statement is the caveat 'never a safety claim', which frames interpretation rather than invocation. The agent gets no routing signal.

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

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

The readOnlyHint already covers safety, and the description adds meaningful behavioral detail: criticalHop identifies the hop responsible for end-to-end time, timings are relative, labels are code-defined, and token choice changes visibility from one install to the whole chain. There is no contradiction with annotations.

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 main output semantics are front-loaded, and each sentence adds a distinct piece of information: output shape, criticalHop meaning, timing/label constraints, token scope, and read-only status. There is no filler repetition.

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?

With no output schema, the description does a strong job explaining what the response contains and how to interpret criticalHop. Minor gaps remain, such as not clarifying how account_token is supplied or whether any time units apply, but the input schema covers invocation details sufficiently.

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 description coverage is 100%, so the schema already documents trace_id, install_id, and read_token. The description adds token-scope context but does not deepen per-parameter semantics, so the baseline of 3 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 defines the tool's output: a nested span waterfall for one user action, with criticalHop semantics and explicit span fields. It is specific enough to distinguish from most siblings, though it lacks an explicit action verb and does not name a sibling for contrast.

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 conveys useful context: it applies to one user action across the stack and explains token-scoped visibility. However, it never states when to prefer this tool over sibling tools or when not to use it, so the usage guidance remains implied rather than explicit.

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

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

The annotations only say readOnlyHint and openWorldHint, so the description carries the burden of explaining behavior. It adds valuable context: the operation involves no upload, addresses are single-use and need no key, `install_command` adds typed commands, and writing files alone does not constitute installation. The 'kit is wired in, reporting switched on, and the app confirmed checked in' line gives an agent a clearer mental model of what receiving a kit means.

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 compact and information-dense, and most sentences contribute content. However, it reads as cryptic and telegraphic ('no upload; the single-use address needs no key, include_files no shell', 'Withheld reply?'), which harms quick comprehension. It is not poorly sized, but it is not cleanly front-loaded or easily scannable.

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?

Despite having no output schema, the description enumerates the key response fields (file_list, version, kit_download_once_url) and addresses special cases like no shell and multiple runtimes. The main gaps are the ambiguous meaning of `runtimes` ('an address each, not a kit's files') and the unexplained 'Withheld reply?' fallback, but overall an agent has enough orientation to invoke and interpret the result.

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 100%, so a baseline of 3 applies. The description goes beyond the schema by distinguishing `runtime` (pick one) from `runtimes` (all in one call), explaining `include_files` as a no-shell fallback, and clarifying that `install_command` adds typed download commands. `files_page` and `project_code` are not elaborated, but the schema already documents them fully.

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 makes clear this tool fetches a Boosthis integration kit for the current project, distinct from removal or verification kits. It even sketches what the reply contains (file_list, version, kit_download_once_url), so an agent can tell this is a delivery/retrieval tool. It loses a point because the phrasing is awkward and some statements ('an address each, not a kit's files') muddy rather than sharpen the core purpose.

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?

There is implied guidance for choosing `runtime` versus `runtimes` and for using `include_files` only when no shell can be run. However, the description never explicitly contrasts this tool with alternatives like `get_removal_kit` or `verify_kit_install`, nor states when to prefer the direct GET fallback beyond the cryptic 'Withheld reply?'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral constraint beyond that: order is load-bearing, and forget() only reaches the server while the key is set. Useful, but it does not describe return format or how the kit should be consumed.

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 scenario is front-loaded, but the body is a single sprawling clause listing kit components and the closing sentence is cryptic. It is short enough but not optimally structured; the enumerated contents would read better as a list.

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?

With no output schema, the description carries the burden of explaining what comes back, and it does enumerate the kit's components. Combined with a read-only, zero-required-parameter shape and fully documented schema, an agent has enough to invoke it, though the ordering caveat is left under-explained.

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 100%, and the schema itself is unusually explicit (runtime enum with 'Naming none is refused, never defaulted'; project_code distinguishing the 8-character code from the shared name). The description adds no parameter meaning beyond the schema, so the baseline of 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?

States a specific resource (a removal kit for uninstalling Boosthis) and enumerates its contents: ordered sequence, kit files, package entries, config, calls to strip, and AI-tool config entries. This clearly distinguishes it from the sibling install-oriented tool boosthis_get_integration_kit without needing to name it. The prose is dense and reads partly like a removal procedure, but the resource is unambiguous.

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 scenario is implied (removing Boosthis from a project), but there is no explicit when-to-use statement, no prerequisites, and no routing against siblings such as boosthis_verify_kit_install or boosthis_which_kits. The trailing note about ordering is a constraint rather than usage guidance.

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

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

Annotations only declare readOnlyHint and openWorldHint=false, so the description usefully adds that fix_template is served only for a registered project and that fix_available:false is accompanied by a fix_note explaining what would change it. It does not describe the skip-persistence side effect (which lives in the schema) or any error behavior for unknown ids.

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?

Front-loads the core action ('Full detail for one rule') and then enumerates the return fields in roughly the order an agent would consume them. Dense but essentially waste-free, though the two-sentence block is somewhat run-on.

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?

With no output schema, the description carries the burden of describing return shape and does so thoroughly: title, when_to_apply, evidence, fix_template, fix_available, fix_note, counterparts, also_applies_here with count. Only error/missing-rule behavior and the skip write semantics are unaddressed.

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 description coverage is 100%, so all four parameters including the enum for skip_decided_by are already documented in structured data. The description adds no syntax or format detail about id, skip, or route_label, 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?

States a specific verb+resource: 'Full detail for one rule,' which contrasts clearly with boosthis_list_rules and boosthis_match_rules_for_code by being singular. It does not name those siblings explicitly, so differentiation is inferred rather than stated.

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?

There is no statement of when to call this versus boosthis_list_rules or boosthis_match_rules_for_code, nor of prerequisites such as needing a rule id obtained from a prior call. Usage is only weakly implied by 'one rule' and by the mention of a registered project.

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

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

The description goes well beyond the readOnlyHint annotation by explaining the five possible job states, the meaning of 'app unheard,' how rhythms are declared, and what fields each job carries. It also explicitly states the tool is read-only and never executes or schedules jobs, which matches and enriches the annotations.

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 dense but every sentence adds value: it defines the job set, explains the states, describes rhythm declaration, lists the returned fields, and states the read-only boundary. It is front-loaded with the core resource and scope.

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?

With no output schema, the description adequately explains what the tool returns: each job's rhythm, allowed lateness, and last run, plus its state. The read-only behavior and the absence of arguments/data are also covered, making the tool fully understandable for an agent.

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 description coverage is 100%, so the parameters are already fully documented by install_id and read_token descriptions. The tool description does not add parameter-specific meaning, which is acceptable under the baseline for high 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 clearly states the tool reports every scheduled job for the runtime, enumerates the possible job states, and explains what each job carries. This makes the resource and scope unambiguous and distinguishes it from sibling tools about changes, promises, and structure.

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 clear context for when to use the tool: when you need scheduled-job status, rhythm, lateness, and last run. It also gives an exclusion boundary with 'Only names and timings, never arguments or data' and 'Boosthis never runs or schedules a job,' though it does not name alternative sibling tools explicitly.

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

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

No parameters and readOnlyHint=true means the safety profile is already covered by annotations. The description adds that results are scoped to 'this runtime' and returned as ids and titles, which is genuinely useful context beyond the annotations, but it doesn't mention size, ordering, or pagination behavior.

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 short sentences, zero waste, and the key scoping constraint ('available to this runtime') is front-loaded. The second sentence functions as a precise pointer to the sibling that consumes the output.

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 zero-param, read-only listing tool with annotations covering safety and no output schema, the description covers purpose and the handoff to boosthis_get_rule. An agent can call it correctly. It lacks only minor operational detail like ordering or result size.

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?

Zero parameters, so the baseline is 4. The description adds a returned-content signal (ids and titles), which is slightly beyond the no-param baseline without needing to explain inputs.

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?

Specific verb+resource: lists performance rules as ids and titles. It also distinguishes itself from its closest sibling by naming boosthis_get_rule as the consumer of this index, so an agent knows this is the discovery entry point.

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?

Positions the tool as 'the index for boosthis_get_rule,' which tells the agent when to call it: first, to discover ids, then hand off to get_rule for details. It stops short of an explicit when-not statement, but the routing relationship is clear.

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

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

Discloses a non-obvious behavior: a project with too few fixed issues returns null rather than a fabricated ratio, which prevents an agent from misreading absent data. It also states 'Read-only; returns no credentials.' Annotations already declare readOnlyHint, so the null-handling rule is the real added value.

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?

Tight, front-loaded definition of the metric followed by empty-data behavior and a safety note. Two sentences carry distinct information; the 'Maintenance Mix:' prefix is slightly redundant with the title but not wasteful.

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 read-only metric with a fully covered schema and no output schema, the description covers concept and null behavior but omits the return shape (what ratio/fields come back) and any unit or interpretation guidance. Adequate but with clear gaps given 28 sibling analytics tools.

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 100%, so window_days and account_token are fully documented in the schema. The description adds no parameter-level detail beyond what is already structured, making 3 the correct baseline.

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?

It defines a specific metric — the ratio of issues fixed pre-impact versus post-impact. The concept is clear but the framing as a 'Maintenance Mix' is idiosyncratic and doesn't obviously distinguish it from siblings like boosthis_trend or boosthis_vigilance without the reader inferring what 'mix' means.

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?

No statement of when to use this tool versus the many sibling analytics tools (trend, vigilance, snapshot, crash_risk). The definition explains what the metric is but gives no route for an agent deciding between these overlapping analytics endpoints.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: output is capped at 8 candidates, ranked by a heuristic text/token match, and the results are explicitly labeled guesses rather than findings whose truth is settled by each rule's when_to_apply. The one gap is return format/shape.

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 sentences with no filler, front-loading what the tool does and the ranking basis before the caveat about interpreting results. Every clause carries information.

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 one-parameter, read-only tool with no output schema, the description covers purpose, ranking basis, result cap, and the critical interpretation caveat. It stops short of describing the return structure (rule ids, scores, ordering) and the meaning of the 'code' input, which would make it fully self-contained.

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 a single required parameter and schema description coverage is 0%, so the schema documents nothing about it. The description only indirectly clarifies that 'code' is the code snippet being matched, adding minimal meaning beyond the field name and no format, size, or language constraints.

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 (ranks) plus resource (Boosthis rules) and the exact mechanism it uses: id tokens and when_to_apply text, capped at 8 candidates. That mechanism is unique among siblings such as boosthis_list_rules and boosthis_get_rule, so an agent can tell them apart without opening a schema.

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?

Usage is only implied: the tool takes a code snippet and returns candidate rules, so the reader infers it is for finding rules relevant to code. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. list_rules vs. this), so guidance is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, yet the description adds real behavioral detail beyond them: one answer per fact, unconfirmed facts carry no answer ("never a limit, never a zero"), scope is limited to this project's own installs, browser/phone reads as a device family with no facts, and unrecognised hosts read unknown rather than production. This is meaningful disclosure of output semantics and failure modes, though nothing about caching, refresh cadence, or response shape.

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 is well front-loaded, but the middle sentence is a densely packed list stitched with em-dashes that is hard to parse on first read, and the caveats about phone/browser and unrecognised hosts could be tightened. Information is mostly load-bearing, but the structure is convoluted rather than crisp.

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?

With no parameters and no output schema, the description must carry the meaning of the returned facts, and it largely does: it names the fact families and explains the source/confirmation semantics and the unconfirmed-fact rule. A reader still cannot know the exact field names or return shape, but for a zero-argument read tool this is close to complete.

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 tool takes zero parameters, which is the baseline-4 case; there are no arguments whose semantics could be clarified. Schema coverage is moot at 0 params.

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 states a specific resource — what the project's hosting platform allows — and enumerates the facts returned (time and memory limits, countdown, processor clock, work-after-reply), each with source and confirmation time. It lacks a crisp leading verb and never contrasts itself against siblings like boosthis_connection_status or boosthis_crash_risk, which also sound environment-related, so an agent must infer differentiation from the text alone.

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?

Usage is only implied: read this when you need platform capability facts for this project. The description says "Read from this project's own installs" and explains how phone/browser and unrecognised hosts behave, but never states when to prefer this tool over alternatives or what other tool to use instead.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the trailing 'Read-only' is largely redundant with that. However, the description adds genuinely valuable interpretive context beyond the structured fields: entries are tagged as measured vs. told, a 'told' item remains a claim regardless of age, and an empty range means 'nothing recorded' rather than 'all well'. This meaning-level disclosure is exactly what annotations cannot carry.

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?

Five short sentences, front-loaded with what the tool assembles before qualifying how to read the results. Every sentence adds a distinct piece of meaning (sources, provenance tagging, empty-state semantics, safety). Slightly dense but no 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?

With no input or output schema, the description carries the full burden of conveying contents, and it does so reasonably well by enumerating the joined record types and the measured/told provenance model. It does not describe ordering guarantees, volume, or time-range behavior, but for a parameterless read-only aggregation it is close to complete.

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 tool takes zero parameters, so the schema baseline is 4 and there is nothing for the description to clarify. No contradiction or omitted param meaning exists.

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 names the resource (a chronological diary of the project assembled from existing Boosthis records) and enumerates the source material it joins: fixes served, claims checked, promises and verdicts, history moves, and changes assistants filed. This distinguishes it from siblings like boosthis_promises or boosthis_ai_changes, which cover only a single source. The verb is somewhat lyrical ('life in order') rather than crisp, but an agent can tell what it returns.

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?

There is no explicit statement of when to call this vs. the single-source siblings (boosthis_promises, boosthis_alerts, boosthis_trend). The only guidance is interpretive ('an empty stretch means nothing was recorded'), which is useful but not about tool selection. An agent must infer that this is the consolidated timeline view.

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

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

Annotations already declare readOnlyHint and closed-world scope, and the description's trailing 'Read-only' merely restates that. The real added value is the return-content taxonomy: 'watched' versus 'remembered only' distinguishes promises that have enforcement from those that do not, which is genuine semantic context beyond the annotations.

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?

Three tightly packed sentences that front-load what the tool returns before clarifying the two promise states. It is dense but each clause carries information; the category explanation earns its space by substituting for a missing output schema.

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?

With no parameters, no output schema, and read-only annotations, the description fills the main gap by explaining the two promise categories and their meaning. It stops short of telling the agent when to reach for this versus remember_promise, but covers what an agent needs to interpret results.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-related gaps exist.

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 identifies the resource (the project's recorded developer promises) and its persisting scope across sessions, which is specific and legible. It lacks an explicit action verb and never names the sibling boosthis_remember_promise, so the read-vs-write distinction relies on the name and the trailing 'Read-only' rather than explicit differentiation.

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?

There is no guidance on when to consult this tool versus alternatives, nor any pointer to boosthis_remember_promise for recording new promises. Usage is only implied by the noun-phrase framing.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, but the description adds real value: it discloses the trust semantics ('Kept as YOUR claim, never evidence'), the visibility limit ('Boosthis cannot see code or commits'), and an input refusal policy. That is substantive context beyond the structured hints.

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?

Four short, front-loaded clauses with no filler; the purpose and constraints come first. Only mild ambiguity in 'File a change' keeps it from a 5.

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 low-complexity write tool with 100% schema coverage and no output schema, the description covers purpose, trust semantics, and input restrictions adequately. It lacks explicit routing among the many sibling tools, a minor gap.

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 description coverage is 100%, so each of the five parameters is already documented in the schema. The description adds semantic framing ('claim, never evidence') but no parameter-specific syntax or format guidance, 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?

States a specific verb+resource: 'File a change you made here, so the next assistant knows.' The purpose of recording a change for continuity is clear, and the constraint that Boosthis cannot see code/commits sharpens the scope. It does not explicitly distinguish itself from siblings like boosthis_ai_changes or boosthis_project_diary, so it lands at 4.

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?

It implies you file a change after making one so the next assistant sees it, but there is no explicit when-to-use/when-not guidance and no comparison to sibling recording tools. Beyond the data-types it refuses (passwords, keys, personal details), the agent gets no routing help.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces 'Read-only.' It adds valuable context beyond annotations by explaining the six answer types, that parts without enough evidence will say so, and that there is no combined score. This goes beyond the safety hints.

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 somewhat verbose and uses poetic phrasing ('did served fixes stop the problems') rather than a concise, direct enumeration. It is structured with a clear opening and a list of six answers, but could be tightened significantly without losing meaning.

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 must explain the return. It does so by specifying six answers with numbers and windows, and notes that evidence may be insufficient. It also clarifies there is no combined score. While the exact output format is not detailed, this is reasonably complete for a read-only check.

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 100%, with both parameters (runtime and install_id) fully described in the schema. The tool description adds no extra parameter meaning, so the baseline of 3 for high schema coverage 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 clearly states the tool evaluates the last release's performance against the project's own measurements, listing six specific aspects it checks. It identifies the resource (release) and the action (check), which is specific. However, it does not explicitly differentiate from sibling tools like boosthis_crash_risk or boosthis_check_claim, so it lacks sibling distinction.

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 implies the tool is for post-release evaluation (e.g., 'How the last release held up'), but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The usage context 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.

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

Adds substantial context beyond the annotations: persistence across later sessions and other assistants, replace-not-duplicate semantics, that nothing is treated as measured until the developer confirms on their project page, and that secrets/personal details are refused rather than stored. These are real behavioral traits the agent can't infer from readOnlyHint/destructiveHint alone.

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?

Front-loaded with the core action and dense with distinct facts; each sentence carries information. The trailing 'This one writes.' is largely redundant with readOnlyHint=false, a minor waste in an otherwise efficient block.

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?

No output schema exists, yet the description covers the confirmation workflow, refusal policy, persistence and idempotency, giving the agent everything needed to call it correctly. Nothing material is missing for a two-parameter write tool.

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 100%, so both parameters are already documented in the schema, including the 240-character limit and example. The description reinforces 'in their words' but adds no format or syntax detail beyond what the schema provides, so the baseline of 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?

States a concrete verb and resource ('Saves what the developer wants kept true ... as a promise on the project'), plus the distinguishing behavior that restating replaces rather than duplicates. This separates it from sibling listing tools like boosthis_promises without opening any schema.

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?

Conveys when this is the right tool ('what the developer wants kept true from now on') and the replacement condition for repeat use. However it never explicitly names an alternative (e.g. boosthis_promises for reading existing promises), so it stops short of full when/when-not guidance.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral context: it is a 'dashboard pointer, never empty,' meaning it always returns data without requiring read_token. It also conditions some metrics on 'where the server has them,' disclosing potential data gaps. This adds meaningful nuance beyond the annotation.

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 key metrics in the first sentence, and the remaining sentences are compact. The phrasing 'No read credentials: a dashboard pointer, never empty' is terse but informative, and the pointer to `your_projects` is a useful aside without bloat.

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?

With no output schema, the description lists the expected metrics (p50/p75/p95, worst, p99, spike ratio, stdev) and notes that some may be absent depending on server data, which gives the agent a good sense of the return shape. It does not fully specify the list structure or ordering, but the first sentence covers the essentials for a simple read-only tool.

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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning; 'No read credentials' suggests read_token may be unnecessary, but it does not clarify when to use project vs install_id. This is adequate but not compensatory beyond schema.

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 produces per-screen performance percentiles (p50/p75/p95), worst rating, p99, spike ratio, and stdev spread, which is a specific and unique resource among siblings. It does not explicitly differentiate itself from similar tools like boosthis_snapshot or boosthis_trend, but the metric list is distinctive enough to identify its purpose.

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 implies usage for retrieving session summary metrics and notes that no read credentials are needed, but it does not explicitly say when to prefer this over alternatives. The reference to `your_projects` hints at an alternative for more projects but does not specify selection criteria, leaving the agent to infer the context.

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

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

The annotations provide readOnlyHint=true and openWorldHint=false, so the description doesn't need to repeat that. It adds value by disclosing the edge case behavior: 'an empty one names its silence, not a clean result' and 'No credentials or none uploaded: a dashboard pointer.' This explains what happens in specific scenarios, beyond just read-only. It doesn't contradict annotations, so no flag.

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 about three sentences and covers a lot of ground: data contents, section parameter behavior, edge cases, and a hint for multiple projects. It's front-loaded with the main purpose. The sentence 'an empty one names its silence, not a clean result' is a bit cryptic and could be clearer, but overall it's efficient and not overly verbose.

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?

With readOnlyHint=true, no output schema, and a relatively simple parameter set, the description covers the key aspects: data contents, section semantics, and edge cases. It could mention that the response is a summary or that no credentials can still return a pointer, but it already hints at that. The description is sufficient for an agent to call it correctly without additional context.

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 description coverage is 75%, leaving the 'section' parameter with no description. The description explains 'section takes a page section (incl. coverage) or `all`', which adds critical meaning for that uncovered parameter. For the other parameters, the schema already has descriptions, but the description doesn't add more detail beyond what's in the schema. This compensates well for the gap.

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 says 'latest upload from one install: per-route rows, per-screen diagnosis, summary and budgets where present,' which clearly identifies the resource and what data it returns. It distinguishes itself from siblings like 'project_diary' and 'session_summary' by focusing on the latest upload snapshot. However, it doesn't explicitly name a sibling as an alternative, so it's not fully distinct.

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?

It gives a clear condition: 'No credentials or none uploaded: a dashboard pointer,' which tells the agent when the tool returns a different result. It also mentions 'More projects: `your_projects`' as a pointer for project selection. However, it doesn't explicitly say when NOT to use this tool or name an alternative sibling for different use cases, so it's not fully explicit.

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

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

The description goes well beyond the readOnlyHint annotation by disclosing output behavior: findings are either measured from real call links or inferred from timing alone, and every answer states how many traced actions were read and over what window. It also warns that too few actions means no clean bill of health, which is valuable behavioral context not present in the schema.

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 dense but every sentence contributes: it front-loads the core purpose, then explains route-level output, the map view, and the measurement caveats. It could be restructured for readability, but it is not padded or redundant.

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 no output schema and minimal input schema, the description provides substantial context: what findings look like, how they are measured, what the map view shows, and how to specify a route. It leaves some ambiguity around default `view` behavior and how `route` interacts with the overall analysis, but the essentials are covered.

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?

With 0% schema description coverage, the description must carry the parameter documentation burden. It explains `route` clearly with a recorded format example and describes the `view`:"map" variant. It does not fully enumerate all possible `view` values or specify defaults, but it compensates meaningfully for the bare schema.

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 identifies the tool as a structural diagnostic for traced app actions, enumerating concrete outputs like single points of failure, call bursts, and route neighborhoods. It differentiates itself from siblings like crash_risk or full_stack_trace by focusing on structural health and route-level analysis rather than individual symptoms.

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 when to use the tool: when you need to understand what is structurally wrong, which route to fix first, or which routes are single points of failure. It does not explicitly name alternatives or state when not to use it, but the usage context is strong enough that an agent can infer the right scenario.

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

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

Annotations already declare readOnlyHint=true, and the description confirms 'Read-only; returns no credentials', adding a security-relevant detail. It also discloses behavior for edge cases: days with no data are marked no_data (unknown, never zero or healthy) and insufficient measurements yield not-enough-data rather than a guess. These go beyond the annotations and are valuable for interpreting results.

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 a single, dense sentence that front-loads the main purpose (one project's last 30 days) and then enumerates specific metrics and the verdict. It is efficient, with every clause adding relevant detail, and does not include fluff or redundancy. It is slightly long but appropriately so for the complexity.

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 there is no output schema, the description explains the output semantics well: it describes the verdict comparison, the handling of no_data and not-enough-data, and the read-only nature. It covers the key behaviors an agent needs to know to interpret results correctly. It does not specify the exact response structure or field names, but for a trend report tool this is sufficient.

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 description coverage is 100%, meaning the schema already fully documents install_id and read_token. The description does not add any new parameter information beyond what the schema provides; it only refers to 'same card' which is already in the schema descriptions. Therefore, the description adds no semantic value for parameters, and the baseline of 3 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 function: it analyzes one project's last 30 days of measurements, including metrics like screen time, poor ratings, crashes, and alerts, plus a 7-day verdict. It specifies the resource (one project) and the time range, distinguishing it from sibling tools that likely cover other aspects (e.g., crash_risk, alerts, session_summary). The verb 'trend' is implicit but the resource and scope are explicit.

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 context about what the tool does but does not explicitly state when to use it versus alternatives. There is no mention of 'use this when you need a trend report' or exclusions like 'use boosthis_session_summary for daily detail'. Usage is implied by the description but not directly guided, leaving the agent to infer.

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

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

With annotations already declaring readOnlyHint and openWorldHint, the description still adds real context: it is read-only, returns no credentials, and specifies the verdict shape (names missing, modified and unexpected paths, each with expected sha256). That is meaningful behavioral disclosure beyond the structured annotations.

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?

Front-loads the core action ('Check ... FILES ON DISK are byte-perfect') and stays to a few dense sentences. The parenthetical endpoint and the trailing 'read-only; returns no credentials' are useful, though the sentence is somewhat packed with clauses.

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?

Despite no output schema, the description explains the verdict's contents and the meaning of a pass, plus the read-only/credential-free safety profile. An agent has what it needs to call this correctly and interpret the result.

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 description coverage is 100%, so the schema already documents all four parameters (files with path/sha256, runtime enum, repair_steps, installed_version). The description reinforces the runtime and byte-perfect intent but adds no syntax or format detail beyond the schema, so the baseline 3 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?

States a specific verb (verify) plus a precise resource and scope: a Boosthis kit's files ON DISK, byte-perfect. Combined with the HTTPS endpoint disclosure and the 'pass proves the files, never that anything is measured yet' qualifier, an agent can distinguish this file-integrity check from siblings like get_integration_kit or check_for_update without opening any schema.

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?

Names an alternative access path (the same check over plain HTTPS) and clarifies the semantic limit of a pass, which guides interpretation. It stops short of stating explicit when-to-use vs when-not conditions relative to related siblings such as check_for_update or release_check, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true, and the description adds critical behavioral details: 'no credentials' beyond the read_token, 'never counted as an AI read', 'No score', and explanations of limitations like 'nothing declared yet, no history, reporting off, kit too old, part never named'. This goes well beyond the annotations to inform the agent of side effects and constraints.

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 dense but every sentence carries meaningful information: the core output, the ordering, what's included, what's excluded, the reasons for exclusions, and remediation guidance. It is front-loaded with the purpose and has no 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?

For a read-only tool with two simple parameters and no output schema, the description fully covers what it returns, what it doesn't, the limitations, and how to resolve issues. There is no missing critical information an agent would need to call it 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?

Schema description coverage is 100%, with both parameters (install_id and read_token) already described. The tool description does not add any extra meaning or usage nuances for these parameters, so the baseline score of 3 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 states a specific verb and resource: it returns 'one project's Vigilance verdict and every watch behind it, worst first', including what each watch watches, its current state, and evidence. It also clearly distinguishes itself as the only tool dealing with vigilance status, making it easy to separate from siblings like boosthis_alerts or boosthis_crash_risk.

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 implies when to use it (to inspect vigilance and its underlying watches) and explicitly states what it cannot do, such as setting a rhythm, directing the user to expectEvery() or the project page instead. It doesn't name alternative sibling tools, but the unique scope makes the usage context clear.

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

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

Annotations already mark it read-only, and the description reinforces that while adding useful behavior: no credentials required, results are never empty, and output is a prioritized list with reasons. It does not discuss limits or project defaults, but it gives meaningful behavior beyond the annotations.

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?

Three short sentences carry the purpose, behavioral guarantees, and a pointer to an alternative with no wasted words. The most decision-relevant information is front-loaded.

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 simple read-only dashboard tool with no output schema, the description supplies the essential return shape (ordered screens with one-line reasons) and the no-credentials guarantee. It is slightly terse about limit and project selection, but the schema fills those gaps.

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?

With 75% schema coverage, most parameters are already documented. The description adds an important clarification that no read credentials are required despite a read_token parameter, and the pointer to your_projects helps with interpreting project scope. The limit parameter remains undocumented in prose, but its default/min/max constraints compensate.

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 names the exact resource: a triage ordering of the worst-rated and slowest screens, with one-line reasons. This scope distinguishes it from the sibling tools, which target alerts, crash risk, exposure, or maintenance, without needing to open their schemas.

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?

Usage context is implied: it is a read-only dashboard pointer that needs no read credentials and never returns empty. The only explicit alternative routing is 'More projects: your_projects,' but there are no stated when-not-to-use conditions or comparisons to other sibling tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false; the description reinforces them with "nothing downloaded or executed" and, more valuably, describes what the call returns (implied kit per file, current registration under this key, files whose contents decide one) despite there being no output schema.

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 core purpose and the sibling relationship are front-loaded, and there is no filler. The middle sentence is a dense, fragmentary list that takes a re-read, but every clause carries load.

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 tool with no output schema, the description covers purpose, sequencing, read-only behavior, and the shape of the return. Nothing essential is missing, though the exact output structure remains only loosely characterized.

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 100%, so the `files` array and its path/dependencies fields are fully documented in the schema (baseline 3). The description adds value beyond it by noting the no-argument behavior (signal table) and that omitted dependencies means "not read" versus empty meaning "none found."

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 outcome: which Boosthis kits the project needs, derived from manifest file names. It distinguishes itself from the sibling boosthis_get_integration_kit by naming it as the following step, so an agent can place it without opening either schema.

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 inventory step before boosthis_get_integration_kit, whose `runtimes` list takes them all at once" clearly positions when to use this versus the sibling that consumes its output, and "With no arguments: the signal table" notes a distinct invocation mode. No explicit exclusion conditions, but the sequencing guidance is strong.

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