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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context: the licensing constraint ('a database this key cannot download is refused here too') and the fact that lookups are not recorded as downloads. These are non-obvious traits that go beyond the safety hints.

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

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

Three tight sentences that front-load the core purpose and reply to each subsequent question (license parity, download-listing side effect). No filler, though the third sentence slightly restates the sibling-separation point.

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 an output schema covering return values and rich annotations covering the safety profile, the description supplies everything else an agent needs: what it returns, the licensing gate, and the non-download side effect. Nothing material 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, including the versioned vs. unversioned dataset_id distinction. The description reinforces the licensing implication of dataset_id but adds little syntax beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('published digests for one database file') and explicitly distinguishes itself from the sibling 'list_downloads' by noting lookups don't appear there. An agent can identify this as the checksum/hash retrieval tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear triggers for use ('verifying a copy you already hold or deciding whether a build has changed since you last fetched it') and one explicit exclusion (not a download, not in list_downloads). It doesn't position itself against database_metadata or list_databases, but the usage context is concrete.

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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds useful non-obvious context the annotations cannot: that this is a cheap preview whose purpose is to avoid multi-GB downloads and to size a transfer.

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 payload contents and immediately followed by the reason to use it. No filler or restatement 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?

An output schema exists, so return values need not be spelled out, and the description still covers content shape, cost/size caveat, and intent. For a single-parameter read-only tool this is complete.

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

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

Schema coverage is 100% and the dataset_id description is unusually rich (versioned vs unversioned id, source of the value, an example). The description itself adds no parameter guidance, so the schema carries this dimension; baseline 3 is correct.

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 (describe/what is inside) and enumerates exactly what is returned: columns and types per format, sample rows, row count, build date, file sizes. The 'without downloading it' framing contrasts it cleanly with the download/checksum 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?

Gives two clear use cases - answering content questions without downloading, and budgeting a transfer before starting one - plus the implicit exclusion that downloading multi-GB files is the alternative. It stops short of naming a sibling tool explicitly, so it is strong context rather than full when/when-not routing.

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, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely non-annotated behavior: results are scoped to the calling key's organization and are volatile, so the agent should re-query rather than hold the result.

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

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

Front-loaded with the core purpose, then the standing enum, then the critical id rule, then the caching caveat. Dense and mostly earned, though the middle sentence is long and packs several distinct concepts together.

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 zero parameters, full annotation coverage, and an output schema, the description only needs to supply meaning the structured fields cannot. It does exactly that by defining the standing enum values and warning which id field downstream tools accept.

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

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

There are no input parameters, so the baseline is 4. The description spends its space on output semantics instead (standing values, base vs versions ids), which is beyond the schema's scope and useful, though it is not parameter semantics per se.

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 (list) and resource (the IP database catalog), and pins down the unit of return: one entry per database FAMILY. It also disambiguates itself from siblings implicitly by describing the catalog view, not metadata, checksums, or downloads.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real operational guidance — answer per key, do not cache, ask again — but never states when to call this versus database_metadata or list_downloads, nor that it is the prerequisite step for discovering the ids other tools need. Usage is implied rather than directed.

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

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

Annotations cover read-only/idempotency safety, but the description adds behavior they cannot express: refusals are included rather than filtered, denial rows carry outcome and http_status, and results are a bounded 200-row window. The explicit warning against interpreting absence as 'never downloaded' is exactly the kind of negative-inference caveat that prevents agent error, though ordering/pagination beyond 'newest first' is left implicit.

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

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

Front-loaded with what the tool returns and its key differentiator before the caveat. It is dense and does earn most of its sentences, though the capitalized emphasis and the quoted 'it stopped working' phrasing add rhetorical weight rather than 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-optional-parameter read tool with an output schema, this covers everything an agent needs: what rows appear, that denials are present, the maximum window size, and the misreading to avoid. Return-value shape is correctly left to the 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?

Schema description coverage is 100% and the limit parameter already documents the 200 cap and the API's 50-row default. The description reinforces the window bound as a semantic constraint but adds no new syntax or meaning for the parameter itself, so the baseline 3 applies.

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

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

States a specific verb and resource (list this organization's download attempts), plus scope (own, newest first) and a distinguishing property (refusals included). An agent can tell instantly that this is the only tool returning per-attempt outcome/http_status data versus the metadata/checksum 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?

Gives three explicit trigger scenarios — explain a failing fetch, confirm a transfer ran, check whether a request was theirs — and notes that no other tool here can supply the denial details. That is concrete when-to-use guidance tied to a differentiator.

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