execute_wcps_query

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the return structure ('structured dictionary indicating success, result_type, original query, the actual result value for scalar and small JSON or file path for large/binary results') and adds an important instruction to show the query and file path to the user. This goes beyond a bare execution description, though it does not mention side effects, error handling, or authentication requirements, which would strengthen it further.

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 four sentences with no filler. The purpose is front-loaded, followed by return type and a key practical instruction in bold. Every sentence earns its place, and the structure guides an agent efficiently.

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 an output schema, explaining return details is not required, and the description already covers the return form. It addresses purpose, usage, and a critical user-facing requirement. It lacks explicit error descriptions or prerequisites, but these are implied by the 'success' field and the presence of documentation siblings, making it adequate for a single-parameter 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 single parameter wcps_query has 0% schema description coverage, so the description must compensate. It implies the query is a WCPS string and mentions capabilities like subsetting and aggregation, but it does not describe the query syntax, provide examples, or link to documentation. This is minimal added value over the parameter name itself; however, the parameter is a well-understood concept, and related doc tools exist, so a mid score 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 verb 'Executes' and the resource 'WCPS query in rasdaman', and further specifies operations (spatio-temporal subsetting, processing, aggregation, filtering) that distinguish it from siblings like list_coverages and describe_coverage. An agent can immediately identify this as the query execution tool.

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 says 'Use this for spatio-temporal subsetting of datacubes, processing, aggregation, filtering', which provides clear context for when to invoke it. However, it does not mention exclusions, alternatives, or prerequisites (e.g., needing a pre-existing coverage), so it falls short of explicit when-not guidance.

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