Rasdaman MCP Server

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

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses the return format ('structured dictionary indicating success, result_type...'), handling of different result types ('scalar and small JSON or file path for large/binary results'), and user-facing instructions ('Show the actual WCPS query and the result file path to the user'). This covers key operational traits beyond basic execution.

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 well-structured and concise: first sentence states purpose, second specifies use cases, third describes returns, and fourth gives important user instructions. Each sentence adds distinct value with zero waste, and it's front-loaded with core functionality, making it efficient and easy to parse.

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 complexity (execution tool with data processing), no annotations, but an output schema exists, the description is largely complete: it covers purpose, usage context, behavioral details (returns, result handling), and user instructions. The output schema likely handles return structure, so the description needn't detail that further. Minor gaps include lack of error handling or prerequisites, but it's sufficient for informed use.

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 0% (parameter 'wcps_query' has no schema description), but the description adds minimal parameter semantics: it mentions 'WCPS query' in the purpose but doesn't explain what a WCPS query is, expected syntax, or examples. With one parameter and low coverage, it partially compensates by contextually linking to the parameter, but lacks detailed guidance, aligning with the baseline for moderate compensation.

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 purpose: 'Executes a Web Coverage Processing Service (WCPS) query in rasdaman' with specific verbs ('executes') and resource ('WCPS query'). It distinguishes from siblings by specifying 'for spatio-temporal subsetting of datacubes, processing, aggregation, filtering' (unlike describe_coverage or list_coverages), but doesn't explicitly contrast with wcps_query_crash_course beyond functional 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 implies usage context ('Use this for spatio-temporal subsetting...') and mentions an alternative implicitly (wcps_query_crash_course suggests learning vs. execution), but lacks explicit guidance on when to choose this tool over siblings like describe_coverage or list_coverages, or any exclusions. It provides basic functional context without clear decision rules.

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