get_result_slice

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

No annotations are provided, so the description carries the full transparency burden. It goes well beyond a basic read description by disclosing: no API call and no cost, complete delivery of named formats versus context-budgeted auto mode, and that statistics for both the slice and full result are always reported. This prevents common misuses, like mistaking a slice maximum for the true maximum.

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, cost/safety, paramter usage, format/budget caveat, and output statistics are each covered exactly once. The key behavioral trait (free/no API call) is front-loaded so an agent can immediately classify this as a cheap read operation.

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 5 parameters, no annotations, and no output schema, the description is remarkably complete: it explains all slicing modes, format behavior and the context-budget nuance, and the statistics guarantee. The input schema covers antimeridian bbox and parameter types, so nothing essential is left unexplained for an agent to call this 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?

Although schema coverage is 100% (baseline 3), the description adds substantial operational meaning beyond the schema: top_n is for "the hottest tiles," bbox for a "sub-area," every_nth for "a downsample," and the formats are mapped to concrete outcomes ("compact" vs "untouched payload"). This gives an agent a practical understanding of how to shape each parameter, not just its type.

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: "Read part or all of an already-collected result from local disk." It clearly distinguishes this from sibling submission/creation tools by noting it "makes no API call" and reads "already-collected" results. The description also enumerates the different slicing modes, leaving no ambiguity about what the tool does.

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 when-to-use guidance: since it "Costs nothing and makes no API call, so use it freely." It also implicitly signals when-not: this is for already-collected results, not for starting new analyses, unlike sibling submit_* and create_* tools. However, it does not explicitly name the alternative tools or state "use submit_* instead when you need a new analysis," so it stops short of a full when-not/alternatives specification.

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