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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description earns credit for adding behavior beyond them: it explains the two operating modes (directory listing vs parsed-row download) and the fields returned for listings (name, path, size, modified), plus the archive's 2013 depth. It omits auth requirements, rate limits, and pagination behavior across the 100/2000 limits.

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

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

Three sentences, front-loaded with the core capability, then the return shapes, then dataset examples, then the usage trigger. No filler and no repeated schema 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?

For a 4-parameter, no-output-schema, no-nested-objects tool, the description is nearly complete: it covers listing output fields, download output ('parsed rows'), dataset naming, and the historical/current distinction. Minor gap is the absence of any note on limits/pagination behavior, though the schema does document the numeric bounds.

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, but the description adds real semantic value by explaining the list-vs-download duality ('downloads one file as parsed rows') that maps directly onto the `download` and `path` parameters, and by naming concrete datasets for `dataset`. It does not go deeper on `limit` semantics than 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 gives a specific verb+resource pair: browse the SPP Marketplace public file archive, listing folders/files or downloading one file as parsed rows. It names concrete datasets (rtbm-lmp-by-location, da-lmp-by-location) and explicitly distinguishes itself from sibling snapshot tools like spp_lmp_latest by contrasting 'historical interval, day or dataset rather than the current snapshot'.

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 states when to use it ('when you need a SPECIFIC historical interval, day or dataset rather than the current snapshot'), which clearly routes the agent away from the current-snapshot siblings. It doesn't explicitly name the sibling tools or state when-not/exclusions beyond the snapshot contrast, 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.