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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows it is not read-only but also not destructive. The description adds the 'no significance' limitation but does not explain what state is changed, what permissions are needed, or what the coarse masses mean operationally. For a non-read-only analysis tool, that leaves important behavior undisclosed.

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 very short and front-loads the method, but it is two dense fragments rather than a structured explanation. It avoids waste, yet the terseness comes at the cost of clarity for an agent.

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 four-parameter analysis tool with no output schema and no parameter descriptions, the definition is far from complete. It gives a high-level method and one caveat but omits return values, input semantics, side effects, and usage 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?

Schema description coverage is 0% across four parameters, and the description does not define run_id, detector, f_low, or masses. 'Detector-frame masses' vaguely gestures at the masses parameter, but it does not explain format, bounds, defaults, or requiredness beyond the schema's required list.

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 a specific technique (PSD-weighted bounded template-bank search) and a limitation (coarse detector-frame masses, no significance), but it never states in plain terms what analyze_detector does or what it returns. It is more specific than a tautology, yet an agent cannot confidently distinguish its purpose from generic analysis without domain knowledge.

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 when-to-use guidance, no prerequisites, and no alternatives among siblings are mentioned. The only usage-adjacent note is 'no significance,' which is a caveat rather than 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?

The description's "returns evidence ID" usefully explains why readOnlyHint is false — the call persists an evidence artifact even though the operation reads like a check. It does not say what a failed check looks like, whether a low-quality verdict raises an error, or whether the evidence record is immutable, so it only partially adds 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?

A single compact sentence with the check targets front-loaded and the return-value clause trailing. No filler, though the terseness tips into under-specification rather than true conciseness.

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 two-required-parameter tool with no output schema and no parameter documentation, the definition is thin: GWOSC flags and "finite samples" are unexplained domain terms, and neither the failure semantics nor the evidence-ID lifecycle is covered. Adequate as a pointer, insufficient as a spec.

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 0% for two required parameters, so the description must carry the burden and does not: no hint about run_id format, valid detector identifiers (e.g. H1/L1/V1), or case sensitivity. An agent could easily pass an invalid detector string.

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?

Uses a specific verb ("Check") with three named resource types — finite samples, signal quality, GWOSC flags — plus the side effect of returning an evidence ID. That is enough to distinguish it from siblings like analyze_detector or verify_artifacts, though it never explicitly names which sibling covers the adjacent case.

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 guidance on when to run this check, whether it must precede fetch_strain or analyze_detector, or what to do with the returned evidence ID. The agent must infer workflow placement from the sibling list alone.

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 already disclose that this is not read-only, is open-world, and is non-destructive. The description adds useful context by saying it creates an immutable run and downloads a bounded official pair, but it does not explain permissions, side effects, or what "immutable run" entails. There is no contradiction with 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 a single front-loaded sentence with no filler. Every phrase contributes to stating the action, resource, and side effect.

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 that downloads data and creates an immutable run, the description is too thin: it omits the event parameter, does not explain the resulting run, and provides no return-value context despite there being no output schema. The annotations cover some safety signals, but the description leaves important operational details unstated.

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 has one optional parameter, event, with a default, but schema description coverage is 0% and the description never mentions the parameter. No meaning is added beyond the bare schema property name.

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 uses a specific verb, "Download," and names the resource, "bounded official H1/L1 strain pair," plus the side effect of creating an immutable run. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as list_events or get_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 guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. The only implied usage is that an agent should call it when it needs to download strain data and create a run.

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 says 'Fetch', which strongly implies a read-only retrieval operation, while the annotations declare readOnlyHint=false. That is a direct contradiction of the safety profile an agent would infer from the text. The source-frame caveat is useful output semantics, but it does not resolve the read-only mismatch.

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 two short sentences and front-loads the core action before the mass-frame caveat. It is efficient, though the all-caps 'AFTER' and terse phrasing make it slightly cryptic rather than fully polished.

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 fetch tool with no output schema, the description should at least explain what run_id refers to and what kind of catalog data is returned. It gives a useful domain caveat about source-frame masses but leaves the required parameter and return contents substantially unexplained.

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 only parameter, run_id, has 0% schema description coverage and is never mentioned in the description. The description adds no information about what run_id identifies, where to obtain it, or what format it expects, so it does not compensate for the schema 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 gives a specific verb ('Fetch') and resource ('published inference') and adds a timing condition ('AFTER analysis'). However, it does not clearly distinguish this tool from siblings such as get_results, and the relationship between 'catalog' and 'published inference' is left implicit.

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 phrase 'AFTER analysis' supplies an implied usage condition, telling the agent this is a post-analysis retrieval step. But there are no explicit alternatives, exclusions, or prerequisites naming sibling tools like get_results or verify_artifacts.

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 establish that the tool is read-only, non-destructive, and closed-world, so the safety profile is covered. The description adds the topical scope of the guide but does not say what form the guide takes, how long it is, or whether it should be consulted before analysis.

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 front-loaded sentence with no filler. It is appropriately sized for a zero-parameter guide tool, even though the comma-separated content list is dense.

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 zero-parameter guide, the description identifies the topics covered but omits the return format and any indication of when it should be used relative to the analysis tools. With no output schema, that leaves the agent with an incomplete picture of the tool's role.

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 are zero parameters and the input schema is empty, so there is no parameter meaning for the description to add. The baseline for a no-parameter 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 names a specific verb ('Get') and enumerates the content domains: workflow, physics scope, privacy, and interpretation limits. This makes clear it is a documentation/meta tool rather than a data operation, though it does not explicitly distinguish itself from siblings like get_catalog or get_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, when-not-to-use, prerequisite, or alternative tool guidance. The content list only weakly implies that an agent should call it when it needs workflow or interpretation context, leaving the trigger 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, destructiveHint=false, and openWorldHint=false, so safety and locality are covered. The description adds one piece of value beyond that: results carry evidence IDs, implying provenance-bearing output. It says nothing about behavior on a nonexistent or incomplete run, result size, or whether repeated calls are stable.

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 front-loaded sentence with no filler and no redundancy. It is efficient, though its brevity borders on under-specification given the undocumented parameter.

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?

The description does convey the shape of the return payload (measurements, cross-detector timing, evidence IDs), which partially compensates for the absence of an output schema. However, with a required run_id that is nowhere defined and no guidance on prerequisites, the definition is only minimally adequate for an agent to invoke 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 0% and run_id is documented nowhere, so the description must carry the burden and does not — it never explains what a run_id identifies, its format, or where the agent obtains one. With one undocumented required parameter, this is a clear gap rather than the zero-parameter baseline of 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?

Uses a specific verb ('Return') with a named payload ('computed detector measurements and cross-detector timing with evidence IDs'), so an agent can tell this is a results-retrieval tool rather than a catalog, guide, or quality-check tool. It stops short of explicitly contrasting itself with siblings like analyze_detector or list_events.

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 alternatives such as analyze_detector or check_data_quality, nor any precondition such as the run needing to be complete. The agent must infer the usage context entirely from the name and the single run_id parameter.

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 adds two useful behavioral cues: the data comes from the official GWOSC catalog and pagination should follow has_more. With annotations already present, the bar is lower, but it still omits page size, ordering, authentication needs, and where has_more appears in the response. The readOnlyHint=false annotation also creates mild tension with a pure listing operation, though it is not an explicit contradiction.

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 compact sentence with no wasted wording. The semicolon construction is slightly cryptic, but the core instruction is front-loaded and easy to scan.

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 paginated listing tool with no output schema, the description is too thin. It references has_more without documenting where it is returned, and it leaves the sole page parameter semantically unexplained, so an agent lacks enough information to paginate confidently.

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 one parameter with 0% schema description coverage, so the description must carry the burden of explaining page semantics. It says only 'one page' and does not clarify whether page is one-indexed, what the default page does, or how large a page is.

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 shape: list one page of the official GWOSC catalog. However, it does not explicitly say these are events or distinguish this operation from the sibling get_catalog, so the agent must infer the relationship from the tool name 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 guidance on when to use list_events versus get_catalog, get_results, or get_guide. The only procedural hint is 'follow has_more explicitly,' which addresses pagination continuation but not tool selection.

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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description does not need to argue about safety, but it should clarify that a write-to-disk artifact is produced. It does convey that an HTML file is emitted and that rendering is offline, yet omits where output lands, whether existing reports are overwritten, and what happens if the run lacks whitened strain data.

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?

One tight sentence that front-loads the primary output types and closes with the report artifact. No filler, though it could have used the remaining space for usage or parameter detail instead of stopping there.

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, no-output-schema tool that writes files, the description covers what is produced but not where, under what conditions, or what run_id must contain. It is minimally adequate but leaves an agent guessing about preconditions and output location.

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 single parameter run_id has zero description coverage in the schema, and the description does not mention it at all — no indication of format, whether it must reference an existing completed run, or how it relates to the plotted data. With only one undocumented parameter the description needed to carry that meaning and does not.

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?

Uses a specific verb ('Render') with concrete outputs: raw/whitened strain plots, Q-transform plots, and an offline HTML evidence report. It is distinguishable from siblings like fetch_strain or analyze_detector, none of which produce reports, though it never explicitly contrasts itself with 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?

There is no statement of when to call this versus the other analysis tools, no prerequisite that the run must already have artifacts, and no note about when a report is warranted. The word 'offline' is the only contextual hint, and it does not guide tool selection.

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, destructiveHint=false and openWorldHint=false, so the safe-read profile is covered. The description adds the meaningful fact that it validates checksums rather than content, but says nothing about what happens on a mismatch (error vs. per-artifact reporting) or how results are returned.

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?

One short sentence, front-loaded with the verb and resource, with the scope caveat immediately following. No filler or 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?

For a one-parameter, read-only tool with annotations covering safety and no output schema, the definition is close to sufficient. It is still thin on result behavior — mismatch reporting and failure modes — which matters for a verification tool whose whole point is returning a verdict.

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 0% and the single parameter run_id is never mentioned in the description. While run_id is largely self-explanatory by name, the description adds no meaning about whether it refers to a run in the catalog, what happens if no artifacts were saved, or the required identifier format.

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?

Uses a specific verb+resource ('Verify saved artifact checksums') and adds a scope clause distinguishing integrity checking from scientific-correctness checking, which separates it from siblings like check_data_quality. It stops short of naming that sibling explicitly, so differentiation is implied 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?

'this checks integrity, not scientific correctness' functions as a clear when-not cue, telling an agent to route correctness questions elsewhere. It gives no named alternative and no prerequisites (e.g. that the run must already have saved artifacts).

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