DataGraph

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

Description adds behavioral context beyond the readOnlyHint annotation by specifying the output contents (node types, relationships, sample queries). No destructive behavior indicated, and the read-only nature is reinforced.

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 sentences, no unnecessary words. Purpose is front-loaded, and the prerequisite advice is concise. 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 simplicity (1 param, no output schema, readOnlyHint annotation), the description is complete: it explains purpose, output contents, and usage prerequisite. No gaps identified.

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 description for the locality parameter adds significant value: states it's required, gives source (list_datasets), and provides concrete examples. With 100% schema coverage, this goes beyond basic schema by adding usage 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?

Description clearly states verb (Get) and resource (graph schema for a locality), and specifies contents (node types, relationships, sample queries). Distinguishes from siblings like query_locality_data and list_datasets.

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 advises to call list_datasets first to get locality codes, providing a prerequisite step. Does not explicitly state when not to use, but the context makes it clear this is for schema exploration before querying.

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?

Annotations already declare readOnlyHint=true, indicating safe read operation. The description adds 'GOSR framework info' but does not contradict annotations. It provides minimal additional behavioral context beyond what annotations convey.

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 a single, front-loaded sentence with no extraneous information. Every word contributes meaning.

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 no parameters, no output schema, and benign annotations, the description adequately informs the agent of the tool's purpose. However, it could hint at the output format (e.g., JSON) for completeness.

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?

There are no parameters, so the schema coverage is 100%. The description correctly does not need to explain parameters, meeting the baseline for zero-parameter tools.

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 retrieves server metadata and framework info, using a specific verb and resource. It distinguishes from sibling tools like get_locality_schema which focus on specific data types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for obtaining server info but provides no explicit guidance on when to use over alternatives like get_usage_stats or query_locality_data. No exclusion criteria are given.

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?

The description adds the behavioral trait 'Requires auth,' which is not present in the annotations. Annotations already declare readOnlyHint=true, and the description complements this with an important usage constraint. No contradiction.

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, consisting of two short sentences that convey the purpose and a key requirement. Every word adds value, and no extraneous information is present.

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 no parameters and no output schema, the description provides complete information: what it does and the authentication requirement. The context signals confirm simplicity, and no additional details seem necessary.

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?

There are no parameters, so the schema coverage is 100% by default (vacuously true). The description does not need to add parameter meanings. Baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check your API usage and quota.' The verb 'check' is specific and the resource ('API usage and quota') is well-defined. It is distinct from sibling tools like get_locality_schema or list_datasets, which focus on different 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 implies when to use the tool (to check usage/quota) and explicitly mentions the requirement for authentication. It does not provide explicit exclusions or alternatives, but given the simplicity and distinct purpose, the guidance is sufficient.

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?

Annotations already declare readOnlyHint=true. The description is consistent and simple, adding no contradictory information. With annotations covering the safety profile, the description does not need to elaborate further, though it could mention if results are paginated or sorted.

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 sentences with no fluff. Front-loaded with the action 'List available datasets' and succinctly notes the optional filter. Every word 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?

For a simple list tool with one optional parameter and no output schema, the description is mostly complete. It could briefly note what the output looks like (e.g., 'returns dataset names and details') but is still sufficient for an agent to select the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one optional parameter 'locality' described as 'Filter by locality code (optional)'. The description repeats this, adding no new semantic meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists datasets with optional filtering by locality. It is a specific verb+resource, and while sibling tools exist (e.g., query_locality_data), the purpose is distinct enough for an agent to differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (list datasets, optionally filtered) but does not provide guidance on when to use this tool versus alternatives like query_locality_data or get_locality_schema. No explicit when-not-to-use or exclusion 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?

Annotations already indicate readOnlyHint and openWorldHint, so the description adds value only by mentioning 'Requires auth'. It does not elaborate on other behavioral traits like performance, result size limits, or side effects. Given the annotations, a score of 3 is appropriate as the description is adequate but not exceptional.

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—just one sentence with two clauses—and front-loads the main purpose. It wastes no words but could benefit from structuring the two modes separately. It earns a 4 for being succinct and clear.

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?

Despite the rich schema, the description falls short for a complex query tool with 5 parameters and two query modes. It does not explain the NL vs Cypher choice, expected output format, or how the locality parameter relates to list_datasets. The lack of output schema further increases the need for a more complete description, which is absent.

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 100% coverage with detailed descriptions on each parameter, including defaults, constraints, and recommendations (e.g., 'MUST include WHERE n.dataset = ...'). The description adds no additional semantic information beyond the schema, so the baseline score of 3 applies.

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 'Query data using natural language or Cypher', specifying both the action and the resource. It distinguishes this tool from siblings like 'get_locality_schema' or 'list_datasets' which handle metadata. However, it could be more specific about 'locality data' to avoid ambiguity.

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 only mentions 'Requires auth' as a prerequisite, providing no guidance on when to use this tool versus alternatives or how to choose between natural language and Cypher modes. It lacks explicit context about usage scenarios or exclusions, leaving the agent without decision support.

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