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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond that: interpretation guidance ('does not prove either source is wrong'), the semantic meaning of 'single_source', the read-only/precomputed nature, and rate-limit behavior. Slight gap: no detail on what 'contextual deltas' means, but annotations carry the safety profile.

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 and informative without being wasteful. The core purpose is front-loaded in the first sentence, followed by usage boundaries and behavioral caveats. It packs many distinct pieces of guidance into a compact space, though the last sentence is slightly long and could be split for readability.

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 a single parameter, 100% schema coverage, rich annotations, and an output schema, the description covers key context: purpose, alternatives, interpretation, read-only behavior, and rate limiting. It lacks a mention of pagination or potential error conditions, but these are minor given the output schema and simple parameter surface.

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 schema already provides a clear description and examples. The description adds the resolution detail (slug or exact display name) by pointing to discoverability via search_datasets)Skip? It enriches the parameter meaning by tying it to the tool's purpose, though the schema already does most of the work.

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 ('Return') and resource ('published cross-source reconciliation group'), and enumerates the returned content (per-member counts, dates, statuses, tolerances, contextual deltas). It also explicitly differentiates from provenance/evidence tools, making its purpose unambiguous against 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?

Explicitly says when to use (compare a dataset with its published cross-source group) and when not to use, naming the alternatives (get_provenance or get_evidence). It also warns that discrepancies require human review)Skip? It explains interpretation caveat, read-only nature, and rate limiting.

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 read-only, idempotent, and non-destructive, but the description adds new context: it reads precomputed data, empty result semantics, no API key requirement, and rate limiting ('roughly one request per second with a small burst'). This exceeds what annotations provide.

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 sentences, each carrying distinct value: purpose, evidence inclusion, usage routing, and operational caveats. No repetition of schema fields or annotations. Front-loaded with the core action and ranking, then conditional and exclusion guidance.

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?

Complete for a read-only query tool with an output schema. It covers purpose, alternatives, empty-result handling, authentication, and rate limits. The output schema already handles return value details, so no further description is needed.

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 nominal context ('minimum publish-reliability grade' maps to min_reliability; 'ranked' relates to limit) but does not materially exceed the schema's parameter descriptions. No compensation needed.

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 ('Return datasets flagged by the latest published anomaly detection') and the ranking criterion ('how far the observed update interval exceeds its threshold'). Explicitly distinguishes from sibling tools by naming what it is not for and pointing to find_deteriorating, find_recovering, find_unreliable, and find_schema_drift.

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?

Gives explicit when-to-use ('Use it for unusual update intervals') and when-not-to-use ('do not use it for worsening freshness, recovery, reliability grades, or structural drift') with named alternatives. This leaves no ambiguity about 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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it reads published manifest data, an empty list means no published dataset has the resolved licence, DataPulse is read-only and requires no API key, and the edge limits clients to roughly one request per second with a small burst. This is useful operational context that annotations do not provide.

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 front-loaded: the core action and output are in the first sentence, followed by usage boundaries and operational notes. Every sentence earns its place, and there is no redundant restating of the tool name or schema fields.

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 tool with a rich schema, clear annotations, and an output schema, the description covers the essential selection and invocation context: what it returns, when to use it, when not to, and operational constraints. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents the licence parameter with examples and a pointer to search_datasets for discovering values. The description adds the notion of 'resolved licence' and the exact-match/alias behavior, which slightly enriches the schema. Since the schema carries most of the burden, a 4 is appropriate rather than a 5.

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 all datasets with the given licence'), a clear resource (datasets by licence), and a summarised output. It also distinguishes itself from siblings by explicitly naming search_datasets and get_provenance as alternatives for different intents, so an agent can select it correctly without opening 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?

The description gives explicit when-to-use guidance ('enumerate what's available under a specific licence for compliance/reuse scoping') and explicit when-not-to-use guidance ('do not use it to discover by topic or inspect a dataset's citation context—use search_datasets or get_provenance instead'). It also clarifies the single-licence scope, leaving no ambiguity about alternatives.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it reads precomputed trend data, an empty result means no deteriorating row survives the filters, DataPulse is read-only and requires no API key, and there is a rate limit of roughly one request per second with a small burst. This is useful operational context that annotations do not provide. It does not contradict 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 dense paragraph that front-loads the core purpose and ranking criterion, then covers exclusions, alternatives, and operational notes. It earns its length by packing in usage guidance and rate-limit context, though it could be slightly more scannable with sentence breaks. No wasted words.

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 has only 2 optional parameters, a rich output schema, and annotations covering read-only/idempotent behavior, the description is complete. It explains what the tool returns, how results are ranked, when to use it, when not to use it, what an empty result means, and the rate limit. An agent has everything needed to select and 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 schema already documents both parameters thoroughly, including defaults, ranges, examples, and semantics. The description adds a small amount of context by mentioning 'minimum historical anomaly rate' and 'staleness slope' ranking, but it does not need to compensate for any schema gap. 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?

The description states a specific verb ('Return'), a specific resource ('datasets whose published freshness trend is deteriorating'), and a ranking criterion ('staleness slope'). It also explicitly distinguishes itself from four sibling tools by name, so an agent can tell it apart from find_anomalies, find_recovering, find_unreliable, and find_schema_drift without opening 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?

The description explicitly says when to use it ('Use it for worsening freshness trends') and when not to use it ('do not use it for anomalies, recovery, reliability grades, or structural drift'), naming the exact alternative tools. It also clarifies that it reads precomputed trend data, so agents know not to recompute it. This is explicit when/when-not/alternatives 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 adds substantial behavioral context beyond the annotations: it reads precomputed trend data, explains the meaning of an empty result, states that it requires no API key, and discloses the rate limit with pacing advice. All of this is useful and consistent with the readOnlyHint, idempotentHint, openWorldHint, and destructiveHint 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 compact and front-loaded: purpose first, then usage guidance, then behavioral/rate-limit details. Every sentence adds necessary information without redundancy or 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 single-parameter read-only tool with an output schema, the description covers purpose, selection criteria, output semantics, authentication, and rate limits. Nothing an agent needs to invoke it correctly is missing from the textual description.

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 'limit' parameter is already well-documented with defaults, bounds, and examples. The description adds a small clarification that omitting limit keeps ranking unchangedebb, but the parameter's core meaning is fully conveyed by the schema, so the baseline score 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 whose published freshness trend is recovering' with a clear ordering ('fastest staleness reductions first'). It also distinguishes itself by naming exact alternatives for other cases, so an agent can immediately tell it apart from sibling 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?

It explicitly says when to use this tool ('Use it for improving freshness trends') and when not to use it, listing the specific sibling tools for deterioration, anomalies, reliability grades, and structural drift. This is the strongest possible guidance for 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 read-only, idempotent, and non-destructive behavior, but the description adds valuable operational context: it reads precomputed drift data, explains that an empty result means no published drift row survives filters, notes DataPulse requires no API key, and warns about the rate limit with pacing guidance. 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 description is dense but every clause earns its place: core behavior, parameter nuance, usage boundaries, empty-result interpretation, auth/rate-limit context, and alternative tools. It front-loads the primary purpose and avoids 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?

The description covers purpose, parameter semantics, behavioral caveats, rate limits, and sibling routing. With an output schema present, the return shape is already documented, so no critical information is missing for an agent to select and invoke the 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 coverage is 100%, so the baseline is 3. The description adds meaningful nuance by framing min_change_count as 'a minimum number of structural transitions' and reinforcing that results are ranked structural-first, which goes slightly beyond the schema's raw parameter descriptions.

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

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

The description opens with a specific verb and resource: 'Return datasets with published structural or record-count drift evidence, ranked with structural changes first.' It clearly distinguishes the tool from siblings by naming the exact purpose (drift detection) and later lists what it is not for.

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 explicitly states when to use the tool and when not to: 'Use it for structural or record-count changes; do not use it for freshness risk, anomalies, trends, or reliability—use find_stale, find_anomalies, find_deteriorating, or find_unreliable instead.' This is model guidance with named alternatives.

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 adds meaningful behavioral context: it reads the published health snapshot, empty results mean no rows met the snapshot-based rule, DataPulse is read-only, no API key is required, and there is a one-request-per-second edge limit with a small burst. These details help an agent set expectations and handle retries.

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 earns its place: the first defines the function, the second and third cover usage and exclusions, and the fourth adds essential behavioral and rate-limit context. It is front-loaded with the core purpose before routing to alternatives.

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, rich annotations, an output schema, and explicit sibling distinctions, this description is complete. It covers what the tool returns, when to use it, what not to use it for, empty-result semantics, authentication, and rate-limit behavior—nothing essential 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 max_age_hours with examples and defaults. The main description does not add extra meaning about the parameter beyond what the input schema already provides, which aligns with the baseline of 3 for high schema coverage.

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

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

The description states a specific verb and resource: 'Return datasets whose status is aging, stale, or degraded, plus datasets missing from the latest health snapshot.' It clearly distinguishes this tool from siblings by naming the relevant risk categories and by referencing the published health snapshot, which anchors its scope.

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 explicit when-to-use guidance: use when an agent needs to know freshness or schema-validity risk and to enumerate candidates. It also gives strong negative guidance: do not use for anomalies, trends, reliability, or drift, and explicitly names find_anomalies, find_deteriorating, find_unreliable, and find_schema_drift as alternatives.

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 valuable behavioral context beyond annotations: it clarifies that reliability measures timeliness of successful freshness observations (not uptime), that sample days are included for evidence depth, that it reads precomputed data, and that DataPulse is read-only with rate limits (roughly one request per second with burst). This is rich behavioral disclosure. The only minor gap is not describing the exact output structure, but the output schema exists, so that's not required.

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 paragraph that front-loads the core purpose and ranking order, then adds usage exclusions, behavioral context, and rate-limit guidance. Every sentence earns its place, though the paragraph is long and could benefit from slight structural separation (e.g., a second sentence for rate limits). It is appropriately sized for the complexity and contains 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?

Given the tool's moderate complexity (2 optional params, output schema present, rich annotations), the description is complete. It covers what the tool returns, how results are ordered, what reliability means, when to use alternatives, how to interpret empty results, and operational constraints (rate limits). An agent has everything needed to select and invoke this tool correctly without opening the schema.

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 parameters (limit and at_or_below_grade) with defaults, examples, and inclusive threshold semantics. The description adds the ranking context ('worst grades and lowest on-time percentages first') and the inclusive threshold meaning ('at or below'), which slightly enhances the schema. However, the schema already explains the inclusive behavior in the at_or_below_grade description, so the added value is marginal. 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?

The description states a specific verb ('Return'), a specific resource ('datasets whose evaluated publish-reliability grade is at or below a threshold'), and a clear scope ('the unreliable ones'). It also distinguishes itself from siblings by naming find_anomalies, find_deteriorating, find_recovering, and find_schema_drift as alternatives for different concerns. This is a clear, specific purpose that an agent can act on.

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 explicitly says when to use it ('Use it for timeliness reliability grades') and when not to use it ('do not use it for individual anomalies, trends, or structural drift'), and names the exact sibling tools to use instead. It also clarifies that an empty result means no published grade meets the threshold, which is a key interpretation guideline. This is exemplary 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds substantial context: it reads precomputed published data, does not fetch upstream or create evidence, and describes a bounded artifact not representing semantic truth, completeness, certification, legal permission, safety, or AI admission. It also discloses DataPulse is read-only, needs no API key, and is rate-limited to roughly one request per second with a burst, giving the agent realistic expectations 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?

The description is longer than typical, but every sentence earns its place: core action, artifact scope, semantic limitations, alternative tools, and rate-limit guidance are all distinct, non-redundant facts. It is front-loaded with the primary purpose and then layers caveats in a logical order, though it could be slightly tightened without losing 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 the tool's complexity, the description is thorough: it specifies the artifact version, what the passport describes and does not describe, the exact meaning of evidence_available=false, authentication and rate limits, and clear routing to sibling tools. The output schema exists, so return values need no description, but all other operational context required for correct invocation is present.

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

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

The input schema has 100% coverage, including a detailed description of dataset_id as a stable slug returned by search_datasets, an example, and the requirement that it must be a slug rather than a display name. The description calls it a 'canonical dataset ID' but adds nothing beyond that; the schema already carries the semantic weight. 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?

The description begins with a specific verb and resource: 'Return one bounded, machine-readable Dataset Passport v1 for a canonical dataset ID.' It also distinguishes itself from siblings by explicitly stating it 'reads the published Passport artifact only; it does not fetch an upstream source or create evidence' and contrasts with 'get_dataset or get_provenance'. This leaves no ambiguity about the tool's function.

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 explicit when-to-use and when-not-to-use guidance: 'Use it for the bounded Passport artifact; do not use it for current health detail or citation context—use get_dataset or get_provenance instead.' It further clarifies the semantics of evidence_available=false and rate-limit behavior, so an agent can decide when to invoke it and what to expect.

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, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it states that absent health rows are reported as unknown rather than probed live (open-world behavior), that DataPulse is read-only and requires no API key, and that rate limits are roughly one request per second with a small burst. This goes beyond the annotations without contradicting them.

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

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

The description is fairly long but packs essential information: purpose, key fields, usage guidance, exclusions, and rate-limit warnings. It is front-loaded with the core functionality before getting into alternatives and constraints. It could be slightly more concise, but every sentence earns its place through actionable 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?

The tool is simple (one parameter, no nested objects) and has an output schema, so the description doesn't need to detail return values. It covers the main use case, alternatives, and operational constraints (rate limiting, no API key, unknown-freshness behavior). The only minor gap is not specifying the exact format of the freshness_signal_source values, but the description does list the possible values.

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 already describes the parameter dataset_id with an example and the requirement of a slug. The description reinforces this by stating it requires the slug, not a display name, which adds slight value. However, since schema coverage is 100%, the baseline of 3 is appropriate; the description's additional clarification is helpful but not critical.

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 verb ('fetch full detail') and resource ('one dataset id'), and specifies the exact fields returned (health status, last-verified timestamp, content_freshness_date, freshness_signal_source). It distinguishes itself from sibling tools by explicitly listing what to use instead for other purposes.

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 ('for one dataset's current published detail', 'to fetch provenance/citation metadata for a dataset found via search_datasets') and when-not-to-use ('do not use it for citation context or a Passport—use get_provenance or get_data_passport instead'). It also names alternatives clearly.

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 readOnly, openWorld, idempotent, and non-destructive annotations, the description discloses crucial runtime behavior: it reads precomputed pipeline evidence rather than live sources, evidence_available=false semantics, the one-request-per-second rate limit with burst, and the DataPulse read-only/no-API-key property. It also warns against inferring current source reachability or truth.

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 long but every sentence carries useful information: field list, workflow sequence, exclusions, caveats, and rate limiting. It is front-loaded with the core purpose and then adds necessary operational detail. Slight redundancy around 'use it for a complete published receipt' and the earlier audit phrasing prevents a perfect 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?

Given the complex sibling landscape and the need to route agents to correct verification tools, the description covers purpose, alternatives, workflow, behavioral caveats, rate limits, and failure semantics. The presence of an output schema and full annotations further reduces the need to document return values or safety, so nothing essential 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 coverage is 100% and the dataset_id parameter is already well described in the schema, including 'stable dataset slug returned by search_datasets' and the requirement to use a slug rather than a display name. The tool description adds little beyond the schema's parameter documentation, 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?

The description states a precise verb and resource: it retrieves the complete published evidence receipt for one dataset and lists the exact fields included. It also distinguishes itself from sibling verification tools by explicitly naming what it is not for, making its purpose 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 gives explicit when-to-use guidance ('deep audit before or alongside verification'), a recommended pipeline order (search_datasets → get_evidence → verify_evidence → verify_attestation), and clear exclusions ('do not use it for a live transport check or signature verification—use verify_evidence or verify_attestation instead'). This is model 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 already mark it read-only, idempotent, and non-destructive. The description goes beyond this by disclosing that it reads the latest published snapshot (and what missing counts mean), that DataPulse requires no API key, and that the edge imposes a rate limit of roughly one request per second with a small burst. This adds meaningful behavioral context that annotations alone do not 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 dense, well-organized sentences. The first sentence front-loads the core function and outputs; the second covers usage, limitations, and operational guidance. Every clause earns its place—no fluff 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?

Given the output schema exists (so return structure doesn't need detailing), the description still summarizes key return contents, specifies when to use it, clarifies data source and completeness implications, and includes rate-limit guidance. Nothing an agent needs to call it correctly is missing.

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

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

The tool has zero parameters, so the baseline is 4 per the rubric. The description does not include any parameter-specific details, which is appropriate since there are none to document. It correctly avoids fabricating meaning for a schema with no properties.

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 precise verb ('Return') and resource ('freshness-at-a-glance summary of the published catalogue'), lists the exact outputs (fresh, aging, stale, and reference counts plus latest health check time), and immediately distinguishes it from a sibling ('do not use it to enumerate affected datasets—use find_stale instead'). This is unambiguous and self-sufficient.

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 states when to use ('catalogue-level freshness context') and when not to ('enumerate affected datasets'), names the alternative tool (find_stale), and adds practical constraints (reads latest snapshot, rate limiting with pace/retry advice). The agent gains clear decision rules without needing to infer anything.

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, covering safety and mutability. The description adds critical behavioral context beyond annotations: it explains the data source (published evidence context), the meaning of absent fields, that it is not a freshness guarantee, that DataPulse requires no API key, and the rate limit (one request per second with small burst). This is strong but not perfect—it could clarify the response shape or error handling, but it goes far beyond what annotations provide.

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 long but front-loaded with the primary use case and return-list summary, then provides usage routing, behavioral caveats, and rate limits. Every sentence serves a purpose, but the density is high and some details (e.g., 'compact published evidence context') are repeated. It is structured logically and not redundant, so it earns a 4.

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?

This is a complex tool with a rich output schema, but the description covers all essential context: when to use, what it returns, what it does not do, the data source semantics, rate limits, and how it fits with sibling tools. Given the existence of an output schema, the description does not need to detail return values, and it is complete enough for an agent to call it correctly. A 5 is justified.

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 the parameter well, including examples and the note about preserving order. The description adds value by explaining the expected format (dataset slugs from search_datasets) and the relationship to get_provenance, which is useful for correct invocation. It slightly over-extends by mentioning get_dataset for display-name resolution, but that is helpful context. Baseline 3 is exceeded because of the added guidance, but not a 5 since the description doesn't add much beyond what the schema has.

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 ('get') and resource (provenance) and clearly enumerates what the tool returns (source, steward, licence/attribution, canonical URL, evidence context, etc.). It is distinct from siblings like get_evidence and verify_evidence, and the description explicitly contrasts it with those tools, so an agent can tell them apart.

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 ('Use when asked can I cite this source?', for citation-ready provenance) and when not to use it ('do not use it for full evidence or a live comparison—use get_evidence or verify_evidence instead'). Provides a recommended pipeline ('search_datasets → verify_dataset → get_provenance') and notes rate limits and retry behavior. This is exemplary 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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: it is discovery-only, not trust verification, and it discloses the rate limit ('roughly one request per second with a small burst, so pace or retry'). It also explains that 'published status' is pipeline context, not a reliability proof. Minor gap: it doesn't describe pagination or what happens when limit is exceeded, but the rate-limit disclosure is strong.

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 well-structured: it front-loads the core purpose, then the trust caveat, then the pipeline guidance, then the rate-limit note. Every sentence earns its place, though the final sentence is long and packs several distinct facts (read-only, no API key, rate limit) into one clause, which slightly reduces scannability.

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 discovery tool with a rich output schema, full parameter documentation, and safety annotations, the description covers the essential context: what it returns, how to use it in the larger workflow, what it does not do, and operational constraints. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters with examples and defaults. The description adds a little context by explaining that source and licence filters are applied before ranking, and that query is topic/task phrasing, but it mostly restates what the schema already provides. 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?

The description states a specific verb ('find'), a resource ('DataPulse's 418 Malaysian public datasets'), and the dimensions by which to search (topic, source, licence). It also explicitly contrasts with trust verification and names the sibling verify_dataset, so an agent can distinguish it from the many sibling 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 gives explicit when-to-use guidance ('Use it to discover candidates; do not use it for a trust decision—use verify_dataset instead') and even names the intended pre-trust pipeline: search_datasets → verify_dataset → get_provenance. It also clarifies the meaning of no matches, which is a usage-relevant edge case.

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. The description adds valuable context beyond annotations: it explains the tool reads precomputed artifacts rather than probing live, that missing component availability explains omitted evidence, and that DataPulse is read-only with no API key required. It also clarifies the tool does not verify signatures, which is a meaningful behavioral disclosure. Minor gap: it doesn't detail the exact structure of the returned trust score or evidence objects, but the output schema likely covers that.

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 well-organized, front-loading the core purpose and then covering exclusions, usage guidance, and operational constraints. Every sentence adds information. It could be slightly more concise, but the density is justified given the need to distinguish from many 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?

For a read-only aggregation tool with a single parameter, full schema coverage, and an output schema, the description is complete. It covers what the tool returns, what it does not do, when to use it, and operational constraints. The output schema handles return-value details, so 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 coverage is 100%, so the schema already documents the single parameter. The description adds value by explaining the parameter is a stable dataset slug returned by search_datasets, giving an example ('fuelprice'), and clarifying that display names are not resolved here. This goes beyond the schema's basic description and examples.

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 aggregates published attestation facts, trust score, numeric components, and evidence for one canonical dataset id. It distinguishes itself from sibling verification tools by explicitly naming verify_attestation, verify_dataset, and verify_evidence as alternatives.

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 explicitly states when to use this tool ('assemble the published trust view') and when not to use it ('do not use it for receipt verification, live comparison, or signature verification'), naming the specific sibling tools to use instead. It also provides operational guidance about rate limits and retry behavior.

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 readOnly/openWorld/idempotent, and the description adds non-redundant behavioral context: it reads persisted records, zero totals mean no retained records, requires no API key, and the edge is rate-limited to roughly one request per second. This goes 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?

Every sentence earns its place: purpose, return shape, when-to-use/alternatives, and behavioral caveats. The most important scoping and exclusion information is front-loaded before lower-level 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?

Complete for a read-only aggregate tool: parameters are fully covered, return values are explained, alternatives are named, and operational constraints (rate limit, no API key, zero-total meaning) are given. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters with examples and constraints. The description adds the aggregate 'inclusive ISO date range' framing and an example range, but does not carry the semantic burden.

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 ('aggregate') and resource ('tool usage') with an explicit inclusive ISO date range and enumerates the exact return metrics. It also distinguishes itself from the data-quality find_* siblings, so an agent can select it correctly.

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 says to use it for 'aggregate tool activity' and clearly says not to use it for data-quality risks, naming six alternatives in the same tool family. This is unambiguous routing guidance with no reliance on 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond those hints: L2 replay is not run unless replay_chain is set, a failed level reports an unsatisfied check rather than upstream semantic truth, a valid signature proves attestation integrity and scope but not semantic truth or currentness, and DataPulse is read-only with no API key and rate limits of roughly one request per second with a small burst. This is rich, non-obvious behavioral disclosure that an agent needs for correct invocation.

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 earns its place: purpose, scope, exclusions, alternatives, behavioral caveats, and rate limits are all covered. It is somewhat long, but the density of useful routing and behavioral information justifies the length. The most important scoping information is front-loaded in the first sentence, and the rate-limit note is placed at the end where it is still discoverable.

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 (three verification levels, optional replay, rate limits, and multiple sibling tools), the description is complete. It covers what the tool verifies, what it does not verify, when to use it, when not to use it, the effect of the optional parameter, and operational constraints. The output schema exists, so return values need not be described. An agent has everything needed to select and invoke 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 documents both parameters well. The description adds value by explaining the behavioral consequence of replay_chain (slower L2 daily-head replay to a Git tag, omitted for L1 only) and by clarifying that reference can be a dataset slug or an exact published digest reference. It doesn't add syntax details beyond the schema, but it reinforces the semantic distinction between the two parameters and their runtime effects.

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

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

The description opens with a specific verb and resource: 'verify a signed published probe attestation after an evidence audit.' It clearly distinguishes the tool from siblings by naming verify_dataset, verify_evidence, and trust_verdict as alternatives for other verification tasks. The scope of L1/L2/L3 checks is explicitly stated, so an agent can tell exactly what this tool does and what it does not do.

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 and when-not-to-use guidance: use it for signed-attestation integrity, not for published receipt verification, live transport comparison, or aggregate verdicts. It also names the alternatives (verify_dataset, verify_evidence, trust_verdict) and gives a recommended deep-audit sequence: search_datasets → get_evidence → verify_evidence → verify_attestation. This is exemplary 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 provide readOnlyHint, idempotentHint, openWorldHint, and non-destructive hints. The description goes beyond them by disclosing that this verifies precomputed published artifacts rather than live sources, that a failed check does not indicate current upstream availability, that verification is fail-closed, and that semantic truth must not be inferred. 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 description is dense but each sentence carries useful information: purpose, scope, limitations, pipeline, alternatives, and rate limits. There is minor redundancy around the 'verifies published artifacts, not a live source' point, but the front-loaded purpose and the clear structure keep it 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?

For a tool with this complexity and an existing output schema, the description covers all needed operational context: when to use, what it returns, what it cannot tell the agent, alternatives, pipeline ordering, read-only auth behavior, and rate limits. 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 fully documents both parameters, including the required slug semantics and the include_proof_steps behavior. The description does not meaningfully add parameter-level detail 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?

States a specific verb (verify) and resource (dataset), plus a clear scope: a single-call pre-trust check for questions about currentness/staleness/freshness. It also distinguishes itself from the sibling verify_evidence and verify_attestation by naming what it is not, so an agent can route correctly without opening other 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?

Explicitly says when to use it ('pre-trust check', 'before relying on data'), when not to use it ('live transport comparison' or 'attestation-chain verification'), names the alternative tools, and even gives the intended pipeline order: search_datasets → verify_dataset → get_provenance. Rate-limit pacing guidance is also included.

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 annotations by disclosing that the live check is an observation, not semantic truth; that it does not recompute content dates, record counts, or shape fingerprints; that results are ephemeral and do not update published health artifacts; and that an unreachable or not_verifiable verdict only means the live comparison could not establish a match. It also discloses rate limits (roughly one request per second with a small burst) and that DataPulse is read-only and requires no API key. This is rich behavioral context that complements the readOnlyHint and idempotentHint annotations without contradicting them.

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

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

The description is dense but well-structured, front-loading the primary use case and verdict types before moving to exclusions and rate-limit details. It is longer than strictly necessary, but every sentence carries meaningful information: the observation caveat, ephemeral results, workflow sequence, exclusions, and rate limits all earn their place. The only minor issue is that the final sentence packs several distinct facts (unreachable verdict meaning, ephemerality, read-only, no API key, rate limit) into one long sentence, which slightly reduces scannability.

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 parameter, a rich output schema, and comprehensive annotations, the description is complete. It covers what the tool does, when to use it, what it does not do, what the verdicts mean, rate limits, authentication requirements, and how it fits into a broader audit workflow. An agent has everything needed to select and invoke this tool correctly without opening the schema or output schema.

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 covers the single parameter dataset_id with 100% coverage, including an example and a note about browser-dependent sources returning not_verifiable. The description adds context by explaining the parameter is a stable direct-access dataset slug returned by search_datasets, which helps the agent understand where the value comes from. Since schema coverage is 100%, the baseline is 3, and the description's added context about the slug's origin and the browser-dependent caveat justifies a 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 clearly states the tool performs a rate-limited live-vs-published comparison for a direct-access dataset and returns a verdict. It distinguishes itself from siblings by explicitly naming verify_dataset and verify_attestation as alternatives for different purposes, and the title 'Live-check Published Transport Evidence' reinforces the specific verb and resource.

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 guidance ('Use when a fresh, rate-limited live-vs-published comparison is needed'), gives a concrete example ('after asking whether a government dataset is reachable now'), and explicitly states what not to use it for ('do not use it for published receipt integrity or signed-attestation verification—use verify_dataset or verify_attestation instead'). It also outlines a deep-audit workflow sequence, which is strong usage guidance.

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