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

Annotations already signal readOnly, idempotent, open-world, and non-destructive behavior. The description adds valuable interpretive context beyond that: it warns that a discrepancy requires human review and does not prove either source is wrong, and the term 'published' indicates a precomputed snapshot. This is meaningful behavioral guidance not captured by 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?

Two sentences with no wasted words. The core action and return content are front-loaded, and the caveat about discrepancy interpretation is placed as a separate, purposeful sentence. Every sentence earns its place.

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, single-parameter read-only tool with full annotation coverage and an output schema, the description covers the essential behavioral and informational aspects. It explains what is returned and how to interpret deltas, leaving nothing critical missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with the single parameter dataset_name already documented with examples and a clear description. The tool description adds no additional parameter-level nuance, 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?

The description states a specific verb ('Return') and a specific resource ('published cross-source reconciliation group'), and enumerates what is included (counts, dates, statuses, tolerances, contextual deltas). This clearly distinguishes it from sibling tools like get_freshness_summary or find_anomalies, which target different concerns.

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 its usage context: it returns an existing published reconciliation group rather than computing a fresh check. However, it does not explicitly state when to use this tool over alternatives, name any sibling, or exclude any condition (e.g., 'for live checks, use verify_dataset'). The guidance is adequate but not 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?

Annotations already cover safety (readOnly, openWorld, idempotent, non-destructive), so the description's added behavioral details are useful: results come from the 'latest published anomaly detection', are ranked by interval/threshold deviation, and include pipeline-computed evidence rather than requiring the agent to calculate it. This adds meaningful behavioral context beyond the annotations, though it does not discuss 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?

Two concise sentences: the first front-loads the core purpose and ranking behavior, the second adds the optional filter and a key workflow benefit. Every sentence earns its place with no fluff.

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 that the tool is a read-only query with three optional parameters, a full output schema, and complete parameter descriptions, the description is sufficient: it explains what is returned, the ordering, the optional reliability filter, and that evidence is precomputed. No critical operational detail is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents mode, limit, and min_reliability. The description adds no new semantic detail for mode or limit and only restates the reliability option in nearly the same words as the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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: 'Return datasets flagged by the latest published anomaly detection'. It also defines the ranking criterion ('ranked by how far the observed update interval exceeds its threshold'), which clearly distinguishes this from sibling tools like find_stale, find_deteriorating, and find_recovering. No ambiguity remains about what the tool 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?

The description makes the intended use case clear: query pre-computed, published anomaly results rather than recomputing them ('includes pipeline-computed anomaly and reliability evidence so agents do not recompute it'). It also mentions the optional reliability filter. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds that results are 'summarised' and licence matching is by exact name or alias, but does not go far beyond what the schema and annotations already convey. No contradiction exists.

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 concise sentences with no filler. It front-loads the action and outcome, then adds the relevant use case, making every sentence earn its place.

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 only one required parameter, no nested objects, and an output schema present, the description covers the essential purpose and usage context. The word 'summarised' is slightly vague, but the output schema can reasonably carry the return-format details.

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%, and the description adds little beyond the schema's examples and 'exact licence name or supported alias' note. The parameter meaning is clear, but the description does not enrich it significantly.

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: 'Return all datasets with the given licence, summarised.' It clearly identifies the licensing scope and differentiates itself from broad search tools like search_datasets by focusing on a specific licence.

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?

'Use to enumerate what's available under a specific licence for compliance/reuse scoping' gives a clear context and intent. It does not explicitly mention when not to use it or name alternatives, but the use case is unambiguous.

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 cover read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral detail beyond the annotations: results are ranked by staleness slope, they include pipeline-computed trend and reliability evidence, and callers should not recompute that evidence. This gives an agent meaningful expectations about output content and cost.

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 sentences, starts with the core verb and resource, and contains no filler. Every clause contributes: the ranking criterion, the optional filter, and the note about avoiding recomputation. It is efficiently front-loaded for an agent scanning sibling tools.

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 only two optional parameters, a present output schema, and strong annotations (readOnly, idempotent, non-destructive), the description is complete for selection and invocation. It covers what the tool returns, how it ranks, and an important behavioral caveat about not recomputing evidence. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both limit and min_anomaly_rate in detail. The description adds only slight semantic color ('staleness slope', 'historical anomaly rate') that mostly rephrases the schema. Under the baseline rule for high schema coverage, a 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 specific action: return datasets whose published freshness trend is deteriorating, and it adds a distinct ranking criterion ('staleness slope') that separates it from siblings like find_stale or find_recovering. The resource and condition are unambiguous, and the mention of trend-based deterioration distinguishes this from snapshot staleness tools.

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 when to use the tool: when an agent needs deteriorating freshness trends and wants pipeline-computed trend/evidence rather than recomputing it. It does not explicitly name alternatives or state exclusion conditions, but the 'so agents do not recompute it' note is practical guidance. Clear context without formal when-not-to-use guidance keeps this at a 4.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond the annotations by specifying the sort order and noting that the result includes pipeline-computed trend and publish-reliability evidence.

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 concise sentences with no filler. The first sentence front-loads the core action and ordering; the second adds relevant information about included evidence without repeating schema or annotation content.

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 only one optional parameter and an output schema present, the description is largely complete: it states what is returned, the ordering, and the extra evidence included. A small gap is that it does not explicitly state the tool's scope or filtering behavior, but given the simplicity of the interface, this is minor.

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%, and the only parameter (limit) is fully documented in the schema with range and examples. The description adds no extra parameter semantics, but that is acceptable given the schema already carries the full weight for this simple parameter.

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 ('Return') and a clear resource ('datasets whose published freshness trend is recovering'), and it states the ordering ('fastest staleness reductions first'). It is easily distinguished from sibling tools like find_stale or find_deteriorating because it targets recovery rather than current staleness or decline.

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 this tool would be useful—when the agent needs recovering freshness trends—but it does not explicitly say when to prefer it over alternatives or when not to use it. No sibling tools or exclusion conditions are mentioned, leaving the selection logic 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 establish read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond this: results are ranked with structural changes first, a minimum transition count can be required, and evidence is pipeline-computed. This helps the agent understand what kind of output to expect and how evidence differs from freshness inferences.

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 sentences with no filler. The core purpose and ranking behavior are front-loaded, the optional parameter is mentioned naturally, and the closing clause about pipeline-computed evidence prevents a common misconception. Every sentence contributes useful 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 read-only tool with an output schema and full parameter documentation, this description is nearly complete. It explains the ranking, the optional filter, and the nature of the evidence. It does not detail edge cases like empty results or open-world behavior, but the annotations and output schema cover much of that context, so only minor gaps remain.

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 fully documents both parameters. The description adds a small clarification for min_change_count by calling it 'structural transitions', but this largely mirrors the schema's 'structural fingerprint or column-count transitions'. There is no substantial extra semantic value beyond what the schema provides, 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 clearly states the tool returns datasets with published structural or record-count drift evidence, ranked with structural changes first. It names a specific verb, resource, and ordering behavior, and this distinguishes it from related sibling tools like find_stale or find_anomalies by focusing on drift evidence rather than general freshness.

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 usage context: it should be used when pipeline-computed drift evidence is needed, and agents should not infer drift from freshness alone. It does not explicitly name alternative tools or exclusion conditions, but the guidance is specific enough to prevent the most likely misuse.

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 cover safety (readOnly, openWorld, idempotent, non-destructive), so the description only needs to add selection behavior. It does so by expanding beyond the name: statuses aging/stale/degraded and the subtle inclusion of datasets missing from the snapshot. No auth, rate-limit, or side-effect warnings are needed for a read-only list.

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, front-loaded with the result behavior and followed by a direct usage condition. There is no verbosity or redundant restating of the name/title.

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 one optional parameter, full schema coverage, an output schema, and rich annotations, the description is nearly complete. The only notable gap is positioning against the large set of sibling tools, but the explicit use case mitigates that.

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 fully documents max_age_hours with default, minimum, examples, and a description, so the description adds little parameter-level meaning. With 100% schema coverage, 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?

The description states a specific verb and resource ('Return datasets') with explicit inclusion criteria: status aging/stale/degraded plus datasets missing from the latest health snapshot. This goes beyond the name/title, but it does not explicitly distinguish itself from closely named siblings like find_schema_drift or find_unreliable.

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 provides a clear 'Use when an agent needs to know which data has a freshness or schema-validity risk' statement, which gives an agent actionable context. It stops short of naming alternatives or saying when not to use it, so it lacks explicit exclusions.

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 meaningful behavioral context beyond the annotations: reliability is defined as timeliness of successful freshness observations rather than uptime, results are sorted by worst grades and lowest on-time percentages first, and sample days are included to help agents assess evidence depth. This gives the agent a clear model of what the tool returns and how to interpret it.

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 sentences with no filler. The core behavior and ordering are front-loaded, and the clarifying note about reliability versus uptime earns its place by preventing a common misinterpretation.

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 optional parameters, a full output schema, and strong annotations, this description is complete. It explains what is returned, how results are ordered, how reliability is measured, and why sample days appear, leaving no critical gap for an agent 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 schema already fully documents both parameters, including defaults, ranges, and examples. The description adds some interpretive context around the threshold and ordering, but it does not materially expand on parameters beyond what the schema provides. 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 identifies the verb, resource, and selection criterion: return datasets with a publish-reliability grade at or below a threshold. It also explains the ordering, which helps distinguish this from generic lookups. However, it does not explicitly distinguish itself from closely related sibling tools like find_stale or find_deteriorating.

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 context implies this tool is for finding unreliable datasets by grade, and clarifies that reliability is about timeliness, not uptime. It does not explicitly state when to prefer this over find_stale or other sibling tools, nor does it mention exclusions. Guidance is therefore 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?

Beyond the annotations, the description candidly discloses what the Passport is not: semantic truth, completeness, certification, legal permission, safety, or AI admission. It also clarifies the operation is read-only and artifact-bounded, adding meaningful behavioral context beyond the readOnly and idempotent 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?

Three sentences, each with a distinct role: one states the output, one restricts the operation's scope, and one clarifies the semantic boundaries. No filler or redundancy; the key constraints are 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?

With a single parameter, rich annotations, and an output schema present, the description is complete. It addresses selection criteria, operational boundaries, and semantic interpretation, leaving no critical gap for an agent deciding to call the 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?

The schema already documents the only parameter, including an example and a description, so the baseline is 3. The description simply refers to a 'canonical dataset ID' without adding extra syntax or format detail, and the schema covers 100% of the parameter semantics.

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 ('Return') with a precise resource ('one bounded, machine-readable Dataset Passport v1') and target ('canonical dataset ID'). It clearly distinguishes this tool from siblings by stating it reads only the published Passport artifact rather than fetching upstream sources or creating evidence.

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: this tool is for obtaining the published Passport v1 artifact and should not be used to fetch upstream sources or generate evidence. It does not explicitly name alternative sibling tools, but the scope and exclusions are explicit enough to guide an agent.

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, openWorldHint, and idemmpotentHint, covering safety and idempotency. The description adds value by exposing freshness_signal_source semantics (last_modified, content_parse, none) and the interpretative distinction between unknown freshness and proven stale data, which is behavioral context not present in 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?

Two sentences: one front-loads the operational return value, the other provides the invocation context. There is no extraneous repetition and every sentence contributes actionable 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 single-parameter, read-only, idempotent tool, the description covers what the call returns, the fields the agent can expect, and the intended decision use-case. With no output schema present it could have listed more about failure modes or edge cases, but the level of detail is adequate for selection and invocation.

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 dataset_id is already fully documented in the schema with an example, min_length, and a pointer to the registry. The description does not add further parameter-level meaning, which is acceptable since the schema provides complete 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 states a specific action (return full detail for one dataset id), the exact resource scope, and the key returned fields. It also explicitly distinguishes itself from search_datasets by framing that tool as the discovery step. This makes the reference clear and disambiguated.

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 a clear usage context: use it for a dataset found via search_datasets and to distinguish unknown freshness from proven stale data. It does not explicitly say when not to use it or name alternative tools for health/provenance inspection, so it stops short of a full 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?

Annotations already mark it read-only, open-world, idempotent, and non-destructive. The description adds material behavioral context beyond those hints: it reads published pipeline evidence rather than performing a live fetch, and it explicitly tells the agent not to infer current reachability or semantic truth of the source. This is valuable epistemic boundary-setting that annotations do not express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by the return contents, the critical live-fetch caveat, and the workflow placement. Every sentence earns its place; there is no redundant filler or restatement of the tool name.

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-parameter read-only tool with a robust annotation set and an output schema, the description is complete: it explains what is returned, what the tool is for, what it is not for, and where it fits in the broader tool sequence. Nothing an agent needs to decide whether to call this tool and interpret its result correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter and the input schema already documents dataset_id with an example, a description, and the note that the tool does not fetch the live source. The tool description adds the context that this is for the complete published evidence receipt for one dataset, but it does not substantially change parameter understanding beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action ('deep evidence audit', 'inspect a provenance and evidence receipt') and a specific resource ('complete published evidence receipt'), and enumerates the exact fields returned. It also distinguishes itself from live source fetches and positions itself relative to the verify workflow, so an agent can tell it apart from siblings like verify_evidence.

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: use it for a deep audit before or alongside verification, and the workflow chain 'search_datasets → get_evidence → verify_evidence → verify_attestation' provides ordering guidance. It also warns against using it to infer live source availability. It stops short of explicitly naming alternative tools to avoid, but the guidance is strong.

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 disclose that the tool is readOnly, idempotent, open-world, and non-destructive, so the description only needs to add contextual scope. It usefully adds that the summary covers the 'published catalogue' and includes a health check timestamp, but it does not explain how freshness thresholds are defined or how current the counts are. No contradiction with annotations exists.

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 sentence that front-loads the resource and output type, then lists the exact components of the summary. There is no filler or redundant restatement of the tool name.

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-parameter, read-only tool with an output schema and safety annotations, the description gives the necessary scope and tells the caller what kind of information will come back. Minor gaps remain around staleness definitions and how to route to sibling tools for detailed results, but these are not blockers for correct invocation.

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 and the schema is empty with 100% coverage, so there are no parameter meanings for the description to clarify. Per the baseline for a no-parameter tool, this is handled appropriately.

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 ('Return') and names the resource ('published catalogue') plus the exact output contents: fresh, aging, stale, and reference counts and the latest health check time. This makes it clearly a summary-level tool and distinct from the sibling find_* tools that surface individual records or anomalies.

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 'freshness-at-a-glance summary' implies this is the overview tool to use before drilling into more specific siblings like find_stale or find_anomalies, but the description never explicitly states when to choose it over alternatives or when not to use it. Usage guidance is present only by implication.

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 the operation read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by stating the result is not a freshness guarantee, does not itself verify currency, and that the returned provenance may be cited, which tells the agent how to treat the output and its limitations.

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 trigger use-case is front-loaded, followed by a compact list of returned fields, then the citation-binding guidance and an explicit caveat. The pre-trust workflow sentence earns its place as routing context; no sentence is wasted 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 read-only provenance tool with a rich output schema and fully documented parameters, the description covers trigger, scope, return contents, limitations, and the intended surrounding workflow. There is no meaningful missing context that an agent would need to select or 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?

The schema fully documents dataset_ids with type, min/max, canonical examples, and a note that it is not a live freshness check (100% coverage). The description reinforces dataset identity and citation binding but does not add new parameter-level meaning beyond the schema, 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 opens with a concrete trigger ('can I cite this source?') and states the resource: citation-ready dataset provenance. It enumerates the returned contents (source, steward, licence/attribution, canonical URL, evidence context), making the tool's scope unambiguous and distinguishing it from the sibling verify/evidence tools that serve a different stage.

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 explicitly names when to use the tool ('Use when asked can I cite this source?, for licence and attribution, or for citation-ready provenance'). It also gives a pre-trust workflow (search_datasets -> verify_dataset -> get_provenance) and warns that this is not a freshness check, though it does not name alternative tools for freshness or licence search such as get_freshness_summary or find_by_licence.

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 cover readOnly/idempotent safety, so the bar for added behavioral value is met by the description's caveat that 'a status is published pipeline context, not proof that a dataset is current or reliable.' It also discloses return fields and ranking, which is useful beyond 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 3 sentences and front-loads the key 'discovery only' purpose. The exampls in the first sentence are slightly extraneous but useful for grounding the query phrasing; overall no sentence 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?

For a 4-parameter tool with a rich schema and output schema, the description fully equips an agent: purpose, caveats, return content, and a reroute for verification. It even provides a compond tool chain, leaving no practical gap for correct invocation.

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 recaps that query/source/licence are the search dimensions and gives examples, but does not add meaning beyond the detailed schema descriptions already present for each parameter.

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 ('find') and a precise resource ('DataPulse's 418 Malaysian public datasets') with explicit search dimensions: topic, source, or licence. It clearly separates discovery from trust verification, distinguishing itself from sibling tools like verify_dataset and get_provenance 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?

It explicitly says 'Use for discovery only' and states what the tool is not: 'This is not trust verification.' It gives a concrete routing rule for currentness/reliability checks: 'search_datasets → verify_dataset → get_provenance.' This is strong when-to-use versus when-not-to-use 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 mark the tool as read-only, idempotent, and non-destructive, but the description adds valuable behavioral detail: the returned trust score is unsigned, the tool does not re-probe or verify signatures, and the evidence is existing rather than newly computed. This meaningfully exceeds what the annotations convey.

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 well-structured sentences: the first packs in the full return scope with front-loaded content, and the second covers the critical limitation and correct alternative. There is no filler, and every phrase adds decision-relevant 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?

Given one parameter, rich annotations, and an output schema, the description is fully sufficient. It covers what is returned, the unsigned nature of the score, the absence of verification, and the sibling to call instead. Nothing essential is missing for correct invocation.

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 dataset_id is fully described in the schema with an example and minLength, so the schema carries the heavy lifting. The description contributes little beyond restating 'canonical dataset id' and the example, which is already present. Baseline 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Return') and specifies the exact resource: published attestation facts, the unsigned methodology-versioned trust score, numeric components, component_availability reasons, and existing evidence for one canonical dataset id. It also explicitly distinguishes itself from verify_attestation by stating what it does not do, which helps an agent select it correctly among many siblings.

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 clearly states when to use the tool: to aggregate existing published trust data for one canonical dataset id. It also provides an explicit when-not and alternative: 'This tool does not re-probe or verify the signature; call verify_attestation separately.' This is direct, actionable 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 mark the tool as read-only, idempotent, and non-destructive, and the description adds useful behavioral context beyond those: results are anonymous, the date range is inclusive, and legacy identity fields are ignored. It also names the output fields, which orients the caller even though an output schema exists. 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?

Three compact sentences convey the action, date scope, returned fields, and an important caveat. The key verb phrase is front-loaded, and every sentence earns its place without repeating annotations or schema details.

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 2-parameter, read-only aggregate tool, the description is complete: parameters are fully documented, annotations cover safety behavior, an output schema exists, and the anonymous/legacy-identity caveat adds context not available elsewhere. An agent has everything needed to invoke and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents the two ISO date parameters with examples. The description reinforces that the range is inclusive but does not add meaningful parameter semantics beyond what the schema provides, so the high-coverage 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?

The description uses a specific verb-resource pairing: 'Aggregate anonymous tool usage' over an explicit inclusive ISO date range. It clearly distinguishes this aggregate analytics tool from the data-retrieval and verification siblings, and lists the returned aggregate fields so an agent understands exactly what the tool produces.

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 establishes clear context: this is the tool for aggregate, anonymous usage summaries over a date range. The phrases 'anonymous' and 'Legacy identity fields are ignored' impliedly warn against using it for per-identity or per-user analysis, though it does not explicitly name sibling alternatives or state when-not-to-use conditions.

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 significant behavioral detail beyond the readOnlyHint/idempotentHint annotations, explaining exactly what the verification proves and, importantly, what it does not prove. It also discloses the layered verification structure (L1/L2/L3) and the dependency on verify_evidence for live transport, giving agents a transparent picture of the tool's semantics and limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the main action, and every sentence provides distinct value: what it verifies, what it returns, what it does not prove, and how it fits into a broader audit flow. No filler or redundant restatement of the tool name exists.

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 is complete for a read-only verification tool, especially given the rich annotations and full parameter schema. It provides the invocation rationale, the pipeline context, the output categories, and the key caveats, leaving no critical gap for an agent deciding whether and how to call this 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 for parameters is 100%, so the description need not repeat schema details. It adds useful context for replay_chain by describing it as 'optional L2 replay of daily heads to a Git-tag anchor,' which enriches the bare boolean schema. The reference parameter is adequately covered by the schema's examples and description.

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 verifying a signed published probe attestation, with specific outputs (L1 signature, key, time, chain-link checks, optional L2 replay, L3 scope). It distinguishes itself from verify_evidence by explicitly noting that L3 scope requires verify_evidence for live transport, making the tool's role in the audit pipeline 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 description provides explicit when-to-use context ('after an evidence audit') and a concrete deep-audit pipeline: search_datasets → get_evidence → verify_evidence → verify_attestation. It also states a key exclusion: a valid signature does not prove upstream semantic truth or currentness, guiding agents away from using it for those purposes.

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 annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses fail-closed receipt verification, artifact references, and the crucial limitation that it verifies published artifacts and not live upstream availability or semantic truth. It also states what inferences are permitted vs prohibited, which is substantial behavioral context.

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 plus a pipeline. Each sentence carries essential information: scope of use, return contents, and a critical limitation. There is no filler or repetition of schema details, and the most important 'preferred pre-trust check' 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?

With output schema present, return values need not be spelled out. The description covers when to use, what it does, what it does not do, the allowed inferences, and the requested pipeline order. For a two-parameter tool with strong annotations, this is fully sufficient 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 100%, so the parameters are already fully documented in the schema. The description adds useful high-level context (single-call, published artifacts) but does not provide per-parameter meaning beyond what the schema already states, 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?

The description uses a specific verb and resource ('pre-trust check', 'verify before relying') and names the precise class of questions it answers: currency, staleness, unknown freshness, degraded, browser-dependent. It also distinguishes itself from a live source check and mentions the search/verify/provenance pipeline, making its role among siblings clear.

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?

Explicit when-to-use language ('preferred single-call pre-trust check', 'whenever an agent must verify before relying on data') and a clear exclusion ('not a live source check'). The pipeline 'search_datasets → verify_dataset → get_provenance' gives the agent an explicit placement relative to siblings, so no inference is needed.

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=true, idempotentHint=true, and destructiveHint=false, and the description reinforces these by noting results are ephemeral, do not update artifacts, and are an observation rather than semantic truth. The rate-limited live GET behavior is also disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but information-dense: it covers use case, behavior, limitations, and related workflow in three sentences. No irrelevant or redundant content; structure flows logically from when to use to what to expect.

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 an output schema, the description gives enough context about return contents (transport receipts plus verdict types) and explicitly states non-goals (no recomputation, no artifact updates). It also situates the tool within a broader audit workflow, making it complete for correct invocation.

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 required parameter dataset_id is fully described in the schema with a clear meaning, example, and constraint (minLength=1). The description adds direct-access context, so the parameter semantics are complete 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 clearly states the tool's purpose: performing a live-vs-published comparison for a direct-access dataset and returning a verdict. It also distinguishes behavior from deeper audits by directing users to the search_datasets → get_evidence → verify_evidence → verify_attestation path.

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?

Explicitly states when to use the tool (fresh, rate-limited live-vs-published comparison; checking if a government dataset is reachable now) and what it does not do (recompute content dates, record counts, or shape fingerprints; update published health artifacts). Provides an alternative path for deeper audits.

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