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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds which aspects of the table are described (metadata, variables, qualifiers, size), which is useful but not essential. No contradiction with annotations; the added context is moderate.

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 sentence, front-loaded with the verb 'Describe', and contains no redundancy. It is concise but so brief that it omits key information, though that is penalized in other dimensions. For what it says, it is efficiently structured.

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 having strong annotations and an output schema, the description does not explain how to supply the required parameters. The tool appears simple, but the lack of parameter guidance leaves the agent guessing about identifier and table formats. This makes the description incomplete for a safe, 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?

With 0% schema description coverage, the description is the only source for parameter meaning. It fails to explain identifier, table, or version. The agent must infer from parameter names, which are ambiguous (e.g., 'identifier' could be a record ID or table ID). This is a critical gap.

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 resource (a single HEPData table) and the specifics covered (metadata, variables, qualifiers, size). However, it does not contrast with the sibling get_table, which could also describe a table, so the differentiation is left to the reader.

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 offers no guidance on when to use this tool versus siblings like get_table or get_record. There is no mention of prerequisites, conditions, or alternatives. The agent has no basis for selecting this tool over others.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the description faces a low bar. 'Fetch' aligns with the read-only profile and there is no contradiction. The description adds essentially nothing beyond the annotations, which warrants the baseline 3 rather than higher.

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?

A single, front-loaded sentence with zero waste. Every word earns its place; 'HEPData record' scopes the domain immediately.

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 (one flat string parameter) and has an output schema, so return-value documentation is covered. However, the ambiguous 'identifier' semantics and the absence of any usage guidance leave the definition incomplete for a new agent.

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 by explaining the single 'identifier' parameter — but it never says what form it takes (record ID, DOI, access key, etc.). With coverage at 0%, the description fails to carry the burden for the one parameter it has.

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 ('Fetch'), a resource ('JSON-LD metadata'), and a target ('a HEPData record'), so the core purpose is clear. However, it does not differentiate from siblings like get_record or get_record_exports — an agent cannot tell what makes the JSON-LD variant distinct without inspecting the schema or output 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?

No guidance is given on when to use this tool versus any of its 8 siblings, particularly get_record. There are no exclusions, prerequisites, or alternative names mentioned, so the agent is left to infer the 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the dual-mode behavior (metadata vs full JSON) but does not explain how that is controlled or what version selection does. It offers some value beyond the annotations by hinting at the light/version parameters, but lacks specifics about response shape or 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 one efficient sentence with no wasted words. It front-loads the core action and the two output modes. For its length, it is perfectly concise, though brevity comes at the cost of parameter clarity.

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?

With three parameters (one required), an output schema, and no schema coverage in the description, the description is far from complete. It does not explain how to construct a valid request: what identifier format is expected, how light and version affect the response, or how this tool fits with siblings. The output schema exists, so return values are covered, but operational usage is underspecified.

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 only hints that the tool can return 'metadata or full record JSON', which loosely maps to the light boolean, but it does not mention the identifier parameter (required) or the version parameter at all. No meaning is added for these fields beyond the schema, leaving the agent to guess what a null version means or how the required identifier is used.

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 it fetches HEPData record data and distinguishes two modes: metadata or full record JSON. This differentiates it from sibling tools like search_records (which finds records) and get_record_versions (which lists versions), but it does not explicitly name those alternatives. The verb 'Fetch' plus the resource 'HEPData record' is specific, though the distinction between metadata and full JSON is not mapped to the light parameter.

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 on when to use this tool versus any of its siblings. It does not state that this is for retrieving a specific record by identifier, nor does it mention alternatives like get_record_exports or get_record_versions. No exclusions or prerequisites are provided, leaving the agent to infer usage context.

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 annotations already declare the read-only, idempotent, and non-destructive nature, so the safety profile is covered. The description adds the behavioral detail that it returns URLs and does not download files, which is a useful distinction but not extensive. It provides a small amount of extra context beyond the annotations.

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 sentence that front-loads the action and key qualifier. It is concise and avoids unnecessary details, though it may be too brief to convey all necessary context. Still, for a simple tool, this structure is efficient.

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 two parameters (one required) and an output schema, the description is underspecified. It doesn't explain what the export URLs are for, how the version parameter affects them, or how this tool relates to siblings like get_record_versions. The output schema covers return format, so that is fine, but the semantic context 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 has zero description coverage for parameters, so the description carries the full burden. It mentions no parameters at all. The names 'identifier' and 'version' give some surface-level meaning, but the description does not clarify how they are used (e.g., what identifier refers to or what version null means). This is a clear gap.

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

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

The description clearly states the verb-resource pair ('Return ... export URLs') and adds a key qualifier ('without downloading files') that distinguishes it from data retrieval tools. However, it doesn't explicitly name any sibling tool or contrast itself with them, so it relies on the reader to infer its unique role among the listed siblings.

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 'without downloading files' implies the tool is for when the user needs links rather than the actual data, giving some contextual guidance. But there is no explicit statement of when to use this over alternatives like get_record or get_record_versions, nor any exclusions or prerequisites. Usage is 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds that it returns version URLs, which is useful but does not go beyond the annotation's safety profile. It doesn't mention potential lack of filtering, pagination, or other behavioral traits. Since annotations cover the read-only nature, a moderate score is appropriate.

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, concise sentence that directlystates the action and result. It has no redundant words or filler, and the main information is front-loaded. Perfectly concise for its level of detail.

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?

With only one parameter and an output schema present, the description still lacks essential context about the identifier parameter. It also does not clarify how this tool fits with siblings or any usage constraints. Since the parameter is unexplained and no usage context is provided, the description is incomplete for an agent to use it confidently.

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 a single parameter 'identifier' with no description (0% coverage). The tool description does not mention the parameter at all, so it fails to compensate for the schema gap. An agent has no information about what the identifier represents (e.g., a record ID, DOI, or something else) or its expected format, making it difficult to invoke correctly.

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 ('HEPData record versions'), and specifies the output includes 'version-specific record URLs'. This distinguishes it from siblings like get_record (single record) and get_record_exports (exports). 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 provides no guidance on when to use this tool versus alternatives. It does not mention when a version list is needed as opposed to a single record retrieval (get_record) or other sibling tools. No context or exclusions are given, leaving the agent to infer usage from the name alone.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond restating output formats already present in the schema; it does not mention version semantics, error conditions, or any additional side effects.

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, economical sentence that front-loads the primary action and mentions supported formats. It wastes no words, but its brevity contributes to the lack of parameter context; it is concise but not fully informative.

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?

With four parameters (two required) and no parameter descriptions, the tool is under-specified for correct invocation. While an output schema exists, the description does not explain what a 'table' is relative to 'records' or how 'version' affects the result, making it incomplete for an agent to use effectively.

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 does not clarify the meaning or relationship of the four parameters. The terms 'identifier' and 'table' are ambiguous—does 'identifier' identify a record or a table? The description offers no compensation for this ambiguity, leaving invocation error-prone.

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 ('Fetch') and resource ('one HEPData table'), and enumerates output formats. It is specific enough to distinguish from search/list tools, but it does not explicitly differentiate from sibling tools like get_record or describe_table, which could overlap in 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 provides no guidance on when to use this tool versus alternatives such as get_record, describe_table, or list_tables. There are no selection criteria, prerequisites, or disambiguation cues, leaving the agent to infer 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?

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds no additional behavioral context (e.g., pagination, sorting, or what 'advertised' means), but it does not contradict the annotations either.

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 concise sentence with no wasted words and is front-loaded with the core action. It is appropriately short for a simple list operation, though it sacrifices detail for brevity.

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?

While an output schema is present and likely covers the return format, the lack of parameter semantics and usage guidance leaves critical gaps. An agent would need external knowledge to know what 'identifier' refers to (HEPData record ID) and how optional 'version' is used.

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 does not explain either parameter. 'identifier' and 'version' are given without any meaning, so an agent cannot infer what values are expected or how they affect the result.

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 action ('List') and resource ('tables advertised by a HEPData record'), which clearly identifies the tool's purpose and distinguishes it from siblings like describe_table (which describes a specific table) and get_table (which retrieves data).

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. It does not mention that this should be called before selecting a table, nor does it point to siblings like describe_table or get_table for further actions.

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 cover the read-only, open-world, idempotent nature. The description adds only that it uses 'native search syntax', which hints at complexity but does not disclose any behavioral traits such as pagination, result limits, or how the syntax works. It does not contradict the annotations.

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 sentence with no filler words. It is appropriately concise and front-loads the core function without extraneous detail.

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 having an output schema, the description is too vague to guide correct invocation. It does not explain the search syntax, pagination behavior, or how to combine the parameters. An agent without prior knowledge of HEPData would struggle to use 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 compensate for parameter meaning. It does not explain query, page, or size at all. The mention of 'native search syntax' implies query syntax but provides no details on how to construct the query or what the parameters control.

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 a specific verb ('Search'), resource ('HEPData records'), and the method ('native search syntax'). It distinguishes from siblings like get_record by focusing on searching rather than retrieving a specific record.

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. It does not mention any conditions, exclusions, or reference to siblings such as get_record or list_tables, leaving the agent to infer its place in the workflow.

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 convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the specific content returned (health, version, capability metadata), which goes beyond the generic annotation but does not disclose any additional behavioral traits such as authentication requirements, rate limits, or potential variability (though openWorldHint suggests data may vary). It adds some context but not deep behavioral insight, so a 3 is appropriate.

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, concise sentence that front-loads the action and lists exactly what is returned. Every word earns its place with no fluff. It is perfectly sized for the simplicity of the tool.

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 that the tool has no parameters, is read-only (as annotated), and has an output schema available, the description is fully sufficient. It names the three categories of returned information (health, version, capability metadata) and the output schema provides the detailed structure. Nothing an agent needs to call this 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?

The tool has zero parameters, and the input schema is an empty object. According to the rubric, a tool with 0 parameters receives a baseline score of 4 because there are no parameters to explain. The description correctly implies no inputs are needed, and no additional parameter semantics are required.

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 'Return server health, version, and capability metadata' uses a specific verb (Return) and names the exact subjects (health, version, capability metadata). This clearly distinguishes it from sibling tools, which are all data-specific queries (search_records, get_record, list_tables, etc.). An agent can immediately tell this is the tool for server-level introspection, not data access.

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 does not explicitly state when to use or not use this tool, but the context is clear: it is the only tool that returns server metadata among siblings that handle records and tables. There is no explicit exclusion or alternative named, but the purpose is self-evident, and the read-only annotation reinforces that it is a safe diagnostic call. It lacks an explicit 'use this when...' statement, so it falls short of a 5.

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