gdex-mcp

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

No annotations are provided, so the description carries the burden. It does disclose the auth requirement and implies a read-only check, which is useful. However, it does not describe any polling behavior, error cases, side effects, or idempotency; the output schema covers return values but not behavior.

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?

Extremely lean and front-loaded: one purpose sentence plus a one-line argument definition. Every sentence earns its place with no redundancy.

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 one-parameter read-only tool with an output schema, the description is nearly sufficient. But it lacks the surrounding workflow context—such as using this after submit_subset_request or when to prefer list_request_statuses—so it is not fully 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 0%, so the description must compensate. It provides only 'rindex: Request index/ID,' which largely restates the parameter name and gives no guidance on how to obtain the index, what format is expected, or whether it comes from a prior submit response.

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 ('Check'), a specific resource ('status of a specific subsetting request'), and the 'specific' wording distinguishes it from sibling list_request_statuses. 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?

No guidance on when to use this tool versus alternatives like list_request_statuses or submit_subset_request. The only contextual note, 'Requires GDEX_TOKEN,' is a prerequisite, not a usage condition or exclusion.

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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It discloses a key behavior: if a field fails to load, it returns an error object rather than failing the whole call. It also implies a read-only nature (describe operation). While it doesn't mention permissions or rate limits, the partial-failure behavior is a valuable addition beyond the schema.

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 compact and well-structured: a clear one-sentence purpose, a usage directive, a behavioral note, and a parameter explanation. It front-loads the core purpose and avoids redundancy. Every sentence adds value, making it efficient for an agent 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?

The tool is simple with one parameter, and the description explains the parameter format and usage. An output schema exists, so return value structure is already defined. The description covers the purpose, usage context, parameter semantics, and error behavior—nothing critical is missing 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?

The schema only defines dsid as a string with no further meaning. The description's Args section specifies the format ('dNNNNNN') and provides an example ('d083002'), which is essential for the agent to construct a valid call. This goes beyond the schema and fully compensates for the 0% schema description coverage.

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 states a clear action ('Return a combined overview of a dataset') and enumerates the specific fields included (abstract, temporal/spatial coverage, variables, formats, volume). It explicitly distinguishes itself from the sibling get_dataset_field by saying 'Prefer this over calling get_dataset_field repeatedly,' which makes its purpose unambiguous.

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 provides an explicit usage condition: 'Prefer this over calling get_dataset_field repeatedly when the user wants a general summary of a dataset.' This tells the agent when to choose this tool over its obvious alternative. It also mentions a fallback behavior for field load failures, giving context on error handling.

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?

With no annotations, the description carries full burden and does so well: it discloses the recursive traversal behavior, the avoidance of large listings, the possibility of visiting many groups, the early-stop cap, and the stopped_early result flag. This is rich operational detail that annotations would otherwise need to provide.

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?

Although longer than average, every section earns its place: purpose, internal algorithm, usage condition, caveat, start_gindex guidance, early-stop behavior, and parameter details. The single minor redundancy in the example date is not enough to reduce the score.

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?

The description covers the tool's purpose, algorithm, usage context, failure/edge behavior, and all parameter semantics. Since an output schema exists, the description need not enumerate return fields, and nothing decision-relevant appears 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 0%, and the description fully compensates. It defines each parameter with concrete examples and semantics: dsid as 'Dataset ID (dNNNNNN), e.g. d083002', name_pattern as a substring/pattern, start_gindex as an optional root alternative, and max_groups_visited as a safety cap with its default.

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 uses a specific verb and resource: 'Search a dataset's file-group hierarchy for files matching a name pattern.' It also distinguishes itself from siblings by explicitly contrasting with get_file_groups and get_dataset_files, so an agent can identify what this tool uniquely 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?

It gives explicit selection guidance: 'Prefer this over manually drilling with get_file_groups/get_dataset_files when you don't already know roughly where in the hierarchy to look.' It also explains when to pass start_gindex and what to do if max_groups_visited is hit, making the when/alternative decision clear.

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?

With no annotations provided, the description carries the full behavioral burdenhare. It discloses that zarr rows require no variant selection, that reference rows have multiple kerchunk variants, that the '-osdf' variant must be preferred, and that results can be truncated at 300 rows. These are critical non-obvious behaviors that an agent could not infer from the schema alone.

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 dense but every sentence earns its place. It front-loads the core purpose in the first sentence, then provides necessary technical guidance about variant selection, opening methods, truncation, and alternatives. There is no filler or repetition of schema 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 tool with one parameter and an output schema, the description covers all operational concerns: row type semantics, variant selection, URL handling, opening recommendations, output truncation detection, and the sibling tool to use when narrowing results. Nothing an agent needs in order to call the tool correctly 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 0%, but the description compensates fully for the single parameter by giving the format 'dNNNNNN' and a concrete example 'd083002'. This is exactly the kind of semantic information an agent needs to construct a valid call, and it goes well beyond the bare schema definition of 'dsid'.

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: 'Return the list of ARCO variables available for a dataset.' It clearly distinguishes the tool from siblings like search_arco_variables by discussing exact row behavior and variant selection, so an agent knows what function this tool serves 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?

The description explicitly states when to use this tool versus the alternative by noting 'Results are capped at 300 rows... narrow with search_arco_variables if you hit the cap.' This gives an agent a concrete decision rule for choosing between the two related tools. It also provides context for opening the returned URLs, which informs downstream usage.

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?

No annotations are provided, so the description carries the burden of describing behavior. The verb 'Return' implies a read-only operation and the object returned is characterized as a template, which is reasonably transparent for a simple getter. However, it does not describe error behavior, permissions, or the exact format of the returned control file template.

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 two sentences and every part earns its place: the main purpose, the parameter name, the expected format, and an example. It is front-loaded with the action and resource, with no filler or repetition.

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 simple one-parameter getter with an output schema available, the description is largely complete: it names the exact resource, the required parameter, and the parameter format. The main gap is the lack of explicit usage routing to sibling tools, but that is partly covered by the template-specific wording.

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 input schema only defines dsid as a string, while the description adds the required format '(dNNNNNN)' and a concrete example ('d083002'). This is meaningful semantic information beyond the schema and compensates for the 0% schema description coverage.

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: 'Return the control file template for building a subsetting request for a dataset.' This clearly positions the tool as returning a template rather than submitting or validating a request, distinguishing it from siblings like submit_subset_request and validate_subset_request. The dsid format example ('d083002') further sharpens the purpose.

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 phrase 'for building a subsetting request' implies when the tool should be used, but it does not explicitly say when to prefer this over alternatives such as get_data_access, submit_subset_request, or validate_subset_request. No exclusions or prerequisites are mentioned, leaving the routing mostly to inference.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what is returned but does not mention whether access requires authentication, whether URLs are temporary, or how errors are handled. For a data-access tool, this missing context is a significant gap.

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 compact and front-loaded: the primary purpose and outputs appear in the first sentence, followed by a single parameter note. No redundant wording or filler.

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 one-parameter getter with an output schema, the description is close to sufficient: it identifies the resource, the returned access options, and the required argument format. However, the absence of any authentication or access-restriction context, combined with no annotations, leaves the overall calling context incomplete.

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%, so the description must compensate. It does so well by documenting the dsid format as 'dNNNNNN' and providing a concrete example (d083002). This adds meaning beyond the bare schema type of string.

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 states a clear action ('Return data access options for a dataset') and enumerates concrete outputs: download links, Globus URLs, and access methods. It does not explicitly distinguish this from sibling tools like get_dataset_files or describe_dataset, but the resource and output types are specific enough to make the main purpose clear.

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?

Usage context is implied: an agent would call this when it needs download links or access methods for a dataset ID. However, the description gives no explicit guidance about when to prefer this over sibling tools, nor does it mention any prerequisites or exclusions.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation via 'Return' but does not explicitly state it is read-only, nor does it mention error behavior (e.g., invalid field or missing dataset). It does list allowed field values, which adds some context, but lacks explicit safety or error disclosure. Given the simple getter nature, this is a minimal but acceptable level.

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 efficient and well-structured: purpose is stated first, then usage guidance, then parameter details in a compact Args block. There is no fluff or repetition; every sentence earns its place.

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's low complexity (two simple string params) and the presence of an output schema (which covers return format), the description covers purpose, usage, and parameters adequately. It could mention error handling for invalid fields or non-existent datasets, but that is a minor gap given the output schema and the simple nature of the operation.

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%, but the description fully compensates: it provides a concrete example for dsid (d083002) and enumerates all valid field values. This adds meaning far beyond the bare schema, making parameter semantics clear and actionable.

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 states a specific verb and resource: 'Return one metadata field for a dataset.' It explicitly distinguishes from the sibling describe_dataset by naming the scenario where the sibling is preferred, so an agent can tell them apart without opening schemas.

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 explicitly says when to use describe_dataset (general summary covering several fields) and when to use this tool (single field, including fields describe_dataset doesn't cover). This provides clear when-to-use and when-not-to-use guidance, leaving nothing to inference.

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?

With no annotations, the description carries the full burden of behavioral disclosure, and it excels: it details pagination, the 500-row cap with '_truncated': true, the gindex being dataset-specific and unguessable, and the fact that filter_wfile only affects file rows and not subgroup summaries. These are critical behaviors an agent must know to avoid failed calls.

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?

Though lengthy, every sentence earns its place. The key caveat (subgroup vs file rows) is front-loaded, followed by concrete avoidance strategies, then a clean Args section. The structure is logical and free of redundancy.

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's complexity (5 params, no annotations, no output schema shown but present), the description covers all necessary aspects: pagination, truncation, filtering behavior, gindex navigation, and parameter defaults. Since an output schema exists, not describing the return format in detail is acceptable. Nothing an agent needs to invoke correctly 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 0%, so the description fully compensates by listing each parameter (dsid, gindex, page, filter_wfile, fl) with concrete explanations, including examples like 'd083002' for dsid and the date pattern '20220808' for filter_wfile. This adds meaning far beyond the bare schema types.

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 'Return a paginated file listing for a dataset or a specific group', which clearly specifies the action (return), the resource (file listing), and the scope (dataset or group). It also distinguishes itself from siblings like get_file_groups by explicitly referencing that tool for descending one level, making differentiation obvious.

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 provides explicit when-to-use guidance: it explains the unpredictable subgroup-vs-file response, advises calling again with a gindex to go deeper, and offers two strategies (filter_wfile or page) to avoid truncation. It also points to get_file_groups as the alternative when descending a level, giving clear routing instructions.

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?

With no annotations, the description carries full behavioral burden. It clearly indicates a read-only operation ('Return') and specifies the output content, which is useful. However, it does not disclose any access requirements, error conditions, or side effects, and the absence of annotations leaves the safety profile 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?

Two concise sentences plus a single-line args block. The primary verb and resource are front-loaded, and every sentence adds value without redundancy.

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 one-parameter read tool, the description is nearly complete. The dsid is fully documented, representative metadata fields are listed, and an output schema exists to describe return values. It only lacks a hint about how dsid relates to sibling tools like list_datasets or describe_dataset.

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 input schema provides only a string type with no description (0% coverage), but the description fully compensates by explaining the dsid format as 'dNNNNNN' and giving a concrete example, d083002. This makes the sole parameter unambiguous and actionable.

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 clear verb and object: 'Return full metadata for a GDEX dataset', and enumerates content categories (parameters, temporal range, spatial coverage). This distinguishes it from file-list or metrics tools, but it does not differentiate from the sibling 'describe_dataset', which likely has overlapping purpose.

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?

No guidance on when to use this tool versus alternatives. The sibling 'describe_dataset' suggests a possible overlap, but the description provides no conditions, exclusions, or comparisons, leaving the agent without clear selection criteria.

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?

No annotations are present, so the description carries the full burden for behavioral disclosure. The verb 'Return' reasonably implies a read-only operation with no side effects, but the description does not describe metric semantics, units, or behavior for invalid or missing datasets. It is minimally adequate but thin.

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 compact and front-loaded with the core behavior ('Return a per-dataset metric'), followed by a terse, well-formatted argument list. There is no filler or redundant restatement of the tool name.

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 simple two-parameter getter with an output schema, the description covers both parameters and their allowed values, and the output schema handles return shape. The main gap is that it does not explain what each metric means or when to choose this tool over portal-level metrics, but the invocation path is clear.

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%, so the description must compensate. It fully does: dsid is explained with a format (dNNNNNN) and a concrete example, and metric is given an explicit list of allowed values. This adds essential meaning absent from 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 states a clear verb and resource: 'Return a per-dataset metric.' It also enumerates the metric values, which makes the operation concrete. It does not explicitly contrast with the sibling get_portal_metrics, but 'per-dataset' provides enough differentiation.

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?

There is no guidance about when to use this tool versus alternatives such as get_portal_metrics or describe_dataset. The description implies it should be used to fetch dataset metrics, but it does not state exclusions, prerequisites, or a preferred alternative.

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?

With no annotations, the burden is on the text. It fully discloses that only groups are returned, responses stay small, gindex values are unpredictable/dataset-specific, empty responses indicate leaf nodes, and the top level may include ARCO-related groups. This goes well beyond basic mutation/read cues.

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?

Though longer than typical, every sentence contributes: first line states purpose, subsequent paragraphs explain traversal, leaf detection, sibling alternatives, and ARCO recommendation, closing with clean Args. It is front-loaded and well-organized.

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's hierarchical complexity and only two parameters, the description covers the entire workflow: how to start, how to recurse, how to know when to stop, which sibling to call next, and which group variant to prefer. The presence of an output schema removes the need to document return values.

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%, so the description alone explains both parameters. It gives a precise dsid format (dNNNNNN) with example d083002 and defines gindex as an optional group index whose value must be taken from the parent response.

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 ('Return file groups for a dataset') and clarifies the recursion via gindex into child groups. It also names sibling tools (get_dataset_files, find_dataset_files) and differentiates the group-only scope from file listing.

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 explicit walk-through: call, read gindex/url from parent response, pass it next, stop at empty return, then use get_dataset_files. It also points to find_dataset_files as an automation alternative and recommends the Kerchunk group for analysis over raw data.

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?

With no annotations provided, the description must disclose behavioral traits itself. It notably states that results are paginated and explains how to retrieve additional pages using a result_id. It also implies read-only search behavior. However, it does not mention potential rate limits, authentication requirements, or what happens if the time range is invalid, leaving gaps in the behavioral profile.

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 compact: two sentences cover purpose and pagination, followed by a clean, structured Args block. Every sentence carries necessary information—no filler, no redundancy. The front-loaded purpose and immediate pagination note make it 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 the tool's simplicity (3 params, no nested objects) and the presence of an output schema, the description covers the essential context: what it searches, optional filters, and the pagination mechanism. It also specifies parameter formats. It could have mentioned edge cases (e.g., when valid_datetime_min > max), but the output schema likely documents return structure, so overall it is quite 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?

The input schema has 0% description coverage, so the description must fully compensate. It does: it explains dsid as 'Dataset ID (dNNNNNN)' with an example, and clarifies valid_datetime_min/max as 'valid on/after' and 'valid on/before' with explicit format 'YYYY-MM-DD HH:MM'. This adds meaningful semantics beyond the bare schema fields, making parameter usage unambiguous.

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: 'Search for data files containing "cyclone_fix" datatype data', which immediately distinguishes it from sibling filesearch tools (grid, sensor) by datatype. It also mentions optional time filtering, further clarifying the scope. This is a clear, differentiated purpose.

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 makes the use case evident: use this tool when you need cyclone_fix data files, optionally filtered by time. It also gives post-invocation guidance ('use get_filesearch_result_page with the returned result_id to fetch additional pages'). However, it does not explicitly state when not to use it or reference alternatives like get_filesearch_grid_files, so it stops short of full exclusion guidance.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Return' indicates a read-only lookup and the scope of the response is clear, but it does not explicitly state that no state is modified, nor does it mention error/empty-result behavior or any permissions/rate 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?

One purpose sentence followed by a compact Args list. There is no filler, repetition, or unnecessary detail, and the action is front-loaded. Every sentence earns its place.

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?

All three parameters are semantically documented and an output schema exists, so return-value details are not needed. It is slightly vague about what 'other filters' includes and lacks sibling routing, but for a simple lookup tool it is largely 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 description coverage is 0%, but the Args section fully compensates: dsid is documented as 'Dataset ID (dNNNNNN)' with an example, and both datetime parameters get explicit 'YYYY-MM-DD HH:MM' format and restriction semantics. This adds meaningful context beyond the raw 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?

States a specific verb ('Return') and a concrete resource ('valid date range and other filters for cyclone_fix datatype file search'). The cyclone_fix datatype qualifier clearly distinguishes this from sibling filter tools such as get_filesearch_grid_filters and get_filesearch_sensor_filters.

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 phrase 'for cyclone_fix datatype file search' implies when this tool is relevant, but it gives no explicit comparison or alternatives. It does not explain when to choose this over get_filesearch_cyclone_fix_files or the grid/sensor filter tools, so the guidance is only implied.

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?

No annotations are present, so the description must carry the full behavioral burden. It clarifies the returned set is datatype-dependent and limited to a known subset, but it does not state behavior for invalid or unknown dsid, whether the result can be empty, or explicitly confirm that this is a side-effect-free read.

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 two tight sentences with the key scoping and usage rule front-loaded, followed by a compact Args block. No filler or repetition of schema fields.

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 one-parameter read-only tool with an output schema, the description covers the call's purpose, precondition, and parameter format. It could add a note on empty or invalid inputs, but nothing necessary for correct selection and invocation 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 coverage is 0% and the only parameter 'dsid' is documented solely as a string. The description compensates by giving the format pattern 'dNNNNNN' and a concrete example 'd083002', which is exactly what an agent needs to construct the call.

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 the exact operation (Return), the resource (file-search datatypes for a dataset), and the constrained value set ("grid", "cyclone_fix", "sensor"). This immediately distinguishes it from sibling filesearch_* tools that operate on a specific datatype.

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?

Explicitly instructs to 'Call this before the other filesearch_* tools to know which one(s) apply', giving a clear temporal precondition. It also explains why, by noting a dataset only supports search for datatypes it contains.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses pagination behavior and the need to use a result_id for additional pages, and it defines the filter behavior for parameters and time range. It does not describe limits or failure modes, but the output schema likely covers return structure, so this is a strong disclosure.

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 front-loaded with the core purpose, immediately followed by pagination guidance and a prerequisite workflow. The Args list is compact, each line earning its place, with no filler or redundant restatement. It is detailed but still easy to scan.

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 7-parameter search tool with an output schema and no annotations, the description covers the essential context: what the tool searches, which codes are valid and how to find them, how to paginate, and what each parameter means. Nothing critical is missing for an agent to select and invoke the tool 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?

Schema description coverage is 0%, so the description must explain all parameters, and it does. It gives dsid a concrete format example, explains that parameters is required and takes at least one value, provides datetime format for both min/max arguments, and clarifies products, grids, and levels as restrictive filters. This fully compensates for the schema's lack of descriptions.

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 states a clear verb and resource: 'Search for data files containing grid datatype data.' It also lists the filtering dimensions, which distinguishes it from sibling file-search tools like get_filesearch_sensor_files and get_filesearch_cyclone_fix_files. The 'grid' scoping is explicit and prevents confusion with other datatype-specific searches.

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 explicit workflow guidance: call get_filesearch_grid_filters first to discover valid codes, and use get_filesearch_result_page with the returned result_id for pagination. These instructions tell the agent when to use complementary tools and how to handle multi-page results, leaving little to inference.

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?

No annotations are provided, so the description must carry the behavioral burden. It states that the tool returns codes and a date range, which is a read-only discovery operation. However, it does not disclose any side effects, error behavior, or limitations. It also doesn't mention that it is non-destructive, but the verb 'return' implies read-only. The description is adequate but lacks depth on behavioral edge cases.

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 concise and well-structured: a one-sentence purpose followed by a clean Args list. No redundant or extraneous text. The purpose is front-loaded, and the parameter explanations are efficient and complete.

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 discovery tool with 7 parameters and an output schema, the description covers everything needed: it explains what is returned, how to use it (discover codes for the sibling), and explains each parameter. The output schema handles return format details, so the description doesn't need to. No prerequisites or special conditions are left ambiguous.

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%, so the description must fully explain parameters. It does so thoroughly: it specifies the dsid format (dNNNNNN), datetime format ('YYYY-MM-DD HH:MM'), and explains that array parameters restrict to specified codes. This adds significant meaning beyond the bare schema types, fully compensating for the lack of schema descriptions.

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 states a specific action: 'Return the valid parameter/product/grid/level codes and date range' for 'grid' datatype file search. It clearly identifies the resource (dataset) and differentiates from siblings by naming the 'grid' datatype and explicitly mentioning the related get_filesearch_grid_files tool. This is a precise and unambiguous purpose.

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 explicitly says 'Use this to discover the codes to pass to get_filesearch_grid_files', providing a clear when-to-use directive and naming the alternative tool. It also mentions 'optionally narrowed by any filters you already know you want', which gives context for optional filtering. This is strong guidance for tool selection.

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?

With no annotations provided, the description carries the full burden and it does well: it discloses read-only behavior ('Return a page'), the dependence on a previous result_id, and points to the pagination block for navigating further. It does not discuss potential result expiry or invalid page_num behavior, but the core behavioral contract is clear.

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 compact and front-loaded: one sentence states the function and usage, followed by a brief pointer to pagination details, then a clean argument list. Every line earns its place with no vague or redundant wording.

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 simple three-parameter paging tool with an output schema available, the description is complete. It explains how to identify the result, how to page, and where to find pagination metadata. No critical calling information appears to be 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 coverage is 0%, so the description must compensate, and it does for all three parameters. dsid is given a format ('dNNNNNN') with an example, result_id is tied to the previous response, and page_num is defined as the page to retrieve. It could add constraints like 1-based indexing or upper bounds, but the essential semantics are present.

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 states a specific verb ('Return a page of results') and a precise resource ('from a previous get_filesearch_*_files call, by its result_id'). This clearly distinguishes the tool from the sibling get_filesearch_*_files tools, which perform the search itself.

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 explicitly tells the agent to use this tool for paging through file-search results beyond the first page and references the pagination block for num_pages and next_page. It implies the prerequisite of an earlier get_filesearch_*_files call, but does not explicitly name an alternative to avoid.

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?

With no annotations provided, the description must carry the behavioral disclosure burden. It does disclose pagination behavior and parameter format restrictions, but it does not explicitly state that the operation is read-only or side-effect-free. 'Search' implies a query, yet the lack of explicit safety information prevents a higher score.

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 front-loaded: purpose statement, pagination note, then a compact Args block. Each element earns its place, though the Args section could be slightly more concise by integrating schema defaults. Overall it is appropriately sized and readable.

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, the description does not need to explain return values. It covers params and pagination adequately. However, with no annotations, it omits side-effect/safety context and does not reference sibling tools for alternative usage, leaving the agent to infer some operational details.

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%, so the description must compensate. It provides meaningful semantics for each parameter: dsid format with an example, and valid_date_min/max with explicit 'YYYY-MM-DD' formats and filtering semantics. It could further explain the meaning of default empty strings, but the provided details are clear and actionable.

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 function: search for data files containing 'sensor' datatype data, optionally filtered by date range. It includes a specific verb (search), resource (data files with sensor datatype), and distinguishes it from sibling tools like get_filesearch_grid_files and get_filesearch_cyclone_fix_files by the datatype keyword.

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 usage is implied: use this tool when you need sensor datatype data files. It explains pagination with get_filesearch_result_page but does not explicitly mention alternatives or when not to use it, leaving some room for an agent to infer selection among the many filesearch sibling tools.

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?

No annotations are provided, so the description carries the full burden. It discloses that the operation is a read ('Return') and explains date-filter semantics, but does not mention validation behavior, error conditions, or relationship between min/max dates. Adequate for a simple getter, but not rich.

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 compact and front-loaded: one purpose sentence followed by a short parameter list. Every sentence earns its place, and there is no redundant filler.

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?

The description, schema defaults, and existence of an output schema give an agent enough to invoke the tool correctly: required dsid, optional date boundaries, and the tool's purpose. It could be more explicit about when to choose this over sibling filter tools, but that is covered by usage guidance.

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%, so the description must compensate. It does so by specifying the dsid format ('dNNNNNN', example d083002) and defining valid_date_min/max with exact 'YYYY-MM-DD' semantics. This adds meaning beyond the bare schema property names.

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 names a specific verb ('Return') and resource ('valid date range and other filters for sensor datatype file search on a dataset'). This clearly differentiates it from sibling tools that return files or cyclone/grid filters.

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 explicitly scopes usage to the sensor datatype file search context, which tells an agent when this filter tool is relevant. It does not name alternatives or edge cases, but the context is clear enough for an agent to make a reasonable selection.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly indicates a read/return operation and lists the metric types, but it does not disclose output format, caching, or any side effects. The behavior is not misleading, just minimally elaborated.

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 compact, front-loaded with the core action, and every sentence adds value. The argument list is a clear, scannable enumeration without redundancy.

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?

This is a simple single-parameter tool with an output schema present, so the return shape does not need to be in the description. The description supplies the one critical piece of information—the valid metric values—making it complete enough for correct invocation.

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%, and the schema only defines 'metric' as a string with a default. The description compensates fully by enumerating all valid metric values, so an agent knows exactly what to pass.

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 uses a specific verb ('Return') and a clear resource ('GDEX portal-wide metric'), and enumerates the exact metric options. This distinguishes it from dataset-level siblings like get_dataset_metrics.

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 phrase 'portal-wide' implies when to use this tool versus dataset-specific tools, but there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives. Usage context is present but left to inference.

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?

No annotations are provided, so the description carries the burden. It discloses that a GDEX_TOKEN is required, which addresses authentication needs, and implies a read-only operation by 'Return'. However, it does not state what happens for incomplete requests or any error behavior, leaving some behavioral gaps.

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 brief and front-loaded with the core purpose, followed by the authentication requirement and an arg line. No redundant content is present, though the auth note could be integrated with the main sentence.

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?

The tool has one parameter, an output schema, and the description covers purpose, the completion condition, and authentication. It does not explain how rindex relates to other workflow tools, which could be useful, but given the simple structure it is minimally 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?

The schema provides no description for rindex, so the description's 'Request index/ID' adds useful clarification. It does not explain how this index is obtained (e.g., from submit_subset_request) or its format, but for a single parameter it provides baseline meaning beyond 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?

Description uses a specific verb ('Return') and resource ('output files') within the context of a completed subsetting request, making the tool's purpose clear. It does not explicitly name a sibling tool to differentiate, but the 'completed subsetting request' scoping distinguishes it from submission/status tools.

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 phrase 'for a completed subsetting request' provides clear context for when this tool is applicable, implying it should be used after a subsetting request has finished. It does not name alternatives or exclusion conditions, but the context is sufficiently specific to guide tool selection among the siblings.

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?

No annotations are provided, so the description carries the behavioral burden. 'Return' implies a read-only operation, and the dsid default behavior is disclosed, but the description does not explicitly state that the tool has no side effects, requires no special access, or how it behaves on authorization/errors.

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 extremely concise, with the core purpose front-loaded and a single parameter explanation that earns its place. There is no filler or redundant restating of the tool name.

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 simple one-parameter getter with an output schema present, the description covers the essential behavior: what is returned and how the only argument affects the result. The output schema handles return-value detail, so no further elaboration is needed.

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 0%, so the description must compensate. It does this by explaining that dsid is an optional dataset ID and specifying the behavior when omitted ('returns all staff'). It adds meaningful semantics beyond the schema's bare type/default fields, though it does not detail ID format or examples.

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 uses a specific verb ('Return') and resource ('GDEX staff contacts'), and adds the optional dataset filter. It clearly distinguishes this from sibling tools like get_dataset_metadata or get_dataset_field, which target other resources.

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 states the context clearly: it returns staff contacts and can be scoped by passing a dsid, with the default behavior of returning all staff when dsid is omitted. It does not explicitly name alternatives, but no sibling tool overlaps this staff-contact responsibility, so exclusions are not necessary.

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?

With no annotations, the description carries the full burden, and it delivers meaningful behavioral context: it warns about internal-path chunk targets in non-OSDF variants and specifies the exact xr.open_dataset invocation. It doesn't discuss edge cases like empty results, but the output schema likely covers return structure.

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 front-loaded with the core purpose and then efficiently delivers usage guidance, a critical warning, and parameter format. Every sentence earns its place, and the extra length is justified by the need to prevent a likely kerchunk misuse.

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 a single parameter, an output schema, and clear operational instructions, the description is complete: it says when to use the tool, which sibling tools to call, how to open the data, and what dsid format to provide. Nothing essential for correct invocation 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?

The schema only defines dsid as a string, so the description's addition of the format '(dNNNNNN)' and the concrete example 'd083002' is valuable. For a single parameter, this is sufficient practical semantic guidance.

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 states a specific action and resource: 'Check whether Analysis-Ready Cloud-Optimized (ARCO) data is available for a dataset.' It also distinguishes the tool from sibling tools by framing it as a pre-check before raw data access, which helps an agent select it correctly.

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 explicit when-to-use guidance: call this before reaching for raw data files for analysis tasks. It also names sibling tools (get_file_groups, get_arco_variables) and instructs the agent on which variant to use, making the routing decision clear.

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?

No annotations are provided, so the description carries the full burden. It discloses the large catalog size (~1700 datasets) and the need to filter, which is useful behavioral context. However, it doesn't mention authentication, rate limits, or other potential behaviors. It does explain the default limit and cap, but could be more thorough given no annotation support.

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: a clear opening sentence, a practical note about catalog size and filtering guidance, and a compact Args block. It's not overly verbose and every sentence serves a purpose, though the Args section could be slightly more concise.

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's simplicity and the presence of an output schema, the description covers the essential usage: parameters, filtering, paging, and the reason for filtering. It doesn't explain return format (covered by output schema) or prerequisites, but it's complete enough for an agent to call it 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?

Schema description coverage is 0%, so the description must compensate. It does so with an 'Args' section explaining each parameter: query (case-insensitive substring match against id and title), limit (default 50, cap 500), and offset (paging). This adds meaning beyond the bare schema definitions.

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 states a clear verb and resource: 'List datasets available on GDEX, with their IDs and titles.' This is specific and not a tautology. It distinguishes from sibling tools like describe_dataset or get_dataset_metadata, though it doesn't explicitly name them, the purpose is unambiguous.

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 explicit guidance: 'Always pass `query` to filter by keyword unless the user specifically wants to browse the whole catalog page by page.' It also explains paging with limit and offset. It doesn't mention when to use alternative tools, but the context of catalog listing vs. specific dataset retrieval is clear from the purpose.

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?

No annotations are provided, so the description carries the full burden. It does disclose the authentication need (GDEX_TOKEN) and the authenticated-user scope, which is valuable. However, it does not explicitly state that the operation is read-only, nor does it mention pagination, rate limits, or error behavior. The verb 'list' implies non-mutating, but an explicit statement would be stronger.

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 two concise sentences with the primary action front-loaded and no extraneous detail. Every word contributes to either the action, scope, or authentication requirement.

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 are already covered. The description supplies the essential action scope and authentication requirement. Minor gaps such as pagination behavior or explicit read-only confirmation are not critical for a simple zero-parameter list tool, so it is nearly 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?

The tool has zero parameters, and the schema is complete with 100% coverage. There are no parameters to document, so the baseline of 4 applies. No additional parameter information is needed.

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 uses a specific verb and resource: 'List all subsetting request statuses for the authenticated user.' It clearly states the action, the object, and the scope. The word 'all' also distinguishes it from the sibling check_request_status, which likely focuses on a single status.

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 provides no guidance on when to use this tool versus alternatives like check_request_status. It only mentions the GDEX_TOKEN prerequisite, which is a requirement but not a selection criterion. There is no explicit context for choosing this tool over its siblings.

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?

With no annotations provided, the description carries the full burden. It discloses the destructive nature and the token requirement, and it calls out that output files are also deleted. However, it stops short of stating irreversibility, partial-failure behavior, or what happens if the request does not exist.

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 two short sentences plus an Args block. The core behavior is front-loaded, every sentence earns its place, and there is no filler or redundant restating of the schema.

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 low-complexity, single-parameter destructive tool, the description covers purpose, target resource, auth requirement, and the effect on output files. An output schema exists, so return-value details are unnecessary. Only a note on irreversibility would round it out.

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%, so the description must compensate. It does: 'rindex: Request index/ID to purge' gives meaning beyond the bare schema type/title, clarifying that the parameter identifies the request to delete. For a single simple parameter this is sufficient.

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: 'Delete a subsetting request and its output files.' It clearly distinguishes this destructive tool from the many get_* and submit_* siblings, and the single parameter is named and explained.

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 tool's purpose as a deletion/cleanup operation makes its usage context clear, and it explicitly requires GDEX_TOKEN as a prerequisite. It does not name alternative tools or exclusions, but none are needed given the unambiguous destructive scope.

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?

With no annotations, the description carries the behavioral burden. It discloses the kerchunk vs zarr distinction and precisely instructs how to handle the '-osdf' variant and open datasets with xr.open_dataset. This adds significant value beyond a simple search description, though it does not cover every output nuance.

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 structure is efficient: one-sentence purpose up front, followed by necessary variant-handling behavior and a concise Args section. The longer variant guidance is dense but directly actionable, and no sentence is filler.

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?

The description covers purpose, parameters, and the important variant-picking behavior, while the output schema handles return structure. It does not specify matching semantics (substring vs exact, case sensitivity) or explicitly contrast with get_arco_variables, but it is sufficient for correct invocation.

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%, so the description must document both parameters. It does exactly that: dsid is specified as a dNNNNNN ID with an example (d083002), and query is explained as search text matched against variable names. This fully compensates for the schema's lack of descriptions.

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-resource-scope statement: 'Search ARCO variables by name for a dataset.' This clearly distinguishes it from sibling get_arco_variables, especially since it immediately references that tool while focusing on name-based search.

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 the search-by-name use case clearly, so an agent can infer when to invoke it. It references get_arco_variables as context but does not explicitly say when to prefer this tool over that one or list exclusions, so it stops short of full explicit guidance.

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?

With no annotations provided, the description carries the full burden and handles it well: it discloses the authentication requirement, the API's undocumented status vocabulary, the best-effort matching semantics, and what 'timeout' and 'unknown' actually mean. This goes well beyond a generic 'submit and poll' statement.

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 text is front-loaded with the main purpose and alternative, followed by necessary caveats and a clean Args list. Every sentence adds information; nothing is redundant with the schema.

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's complexity and the ambiguity in the underlying API's status vocabulary, the description covers authentication, status interpretation, fallback actions, and parameter semantics. The output schema exists, so return-value documentation is not required from the description.

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%, so the description fully compensates by explaining each parameter's purpose, default, and constraints: request_json references get_control_file_template, poll_interval_s specifies minimum and default, and timeout_s defines the give-up behavior.

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 names a specific verb and resource ('Submit a subset request and poll its status') and clearly distinguishes itself from the sibling tools submit_subset_request and check_request_status. The core behavior and terminal conditions are stated in the first sentence.

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 explicitly tells the agent when to use this tool instead of calling submit_subset_request and manually looping on check_request_status. It also gives concrete follow-up actions for timeout and unknown outcomes, naming the alternative tool to call.

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?

With no annotations, the description carries the full behavioral disclosure burden. It does disclose that GDEX_TOKEN is required, which is useful, but it omits important side effects such as whether the request is asynchronous, whether it returns a request ID, or how it relates to status-checking via check_request_status.

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 compact and front-loaded: it states the purpose and auth requirement first, then gives the argument explanation. Every sentence earns its place with no filler or repetition.

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?

The description is adequate for preparing a request but incomplete about the submission lifecycle. It does not mention whether the tool waits for completion or only queues a request, which is material given the submit_and_wait_for_request sibling. The output schema exists, but behavioral context is still 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?

The schema provides no description coverage for request_json, so the description must compensate. It explains that request_json is a JSON string of the subsetting request body and points to get_control_file_template and validate_subset_request for structure and validation, adding real guidance beyond the raw 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 opens with a clear verb and resource: 'Submit a data subset request to GDEX.' It conveys the primary action and target system, though it does not explicitly differentiate itself from the sibling submit_and_wait_for_request beyond relying on the name difference.

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 practical usage context by directing users to get_control_file_template for the request structure and validate_subset_request for pre-submission checking. It does not explicitly state when to choose this tool over submit_and_wait_for_request, but the preparation workflow is clearly outlined.

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?

With no annotations provided, the description carries the full behavioral burden. It clearly discloses the non-submitting nature of the operation and the validation behavior: checking against the control file template and surfacing missing or unrecognized fields. It doesn't discuss auth or rate limits, but the key no-side-effect trait is covered.

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 compact and front-loaded: it states the core purpose and usage in the first two sentences, then provides a clean structured Args block. There is very little waste, and the minor repetition of 'without submitting anything' reinforces the key behavioral point rather than bloating the text.

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 low complexity, two well-documented parameters, and an output schema that covers return values, the description is nearly complete. It explains what the tool does, when to use it, and what both parameters mean. A brief pointer to how the control file template is obtained or interpreted could add polish, but this is not a significant gap.

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%, but the Args section fully compensates: dsid gets a format constraint (dNNNNNN) and an example, while request_json is explicitly identified as a JSON string of the subsetting request body. This adds meaningful semantics beyond the bare type and title in 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 uses a specific verb and resource: it validates a subset request body against the dataset's control file template, and explicitly states no submission occurs. It distinguishes itself from the sibling submit_subset_request by positioning validation as a pre-submit check.

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 explicitly instructs to use this before submit_subset_request to catch missing or unrecognized fields, avoiding failed API calls. The alternative tool is named and the selection condition is clear, leaving no ambiguity about when to call this tool.

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