水素分子医学文献データベース — Molecular hydrogen medical literature (H2 Papers)

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds contextual detail about the data source (Consumer Affairs Agency) and that results include editorial framing, which goes 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?

Two sentences, front-loaded with the core function and a precise usage trigger. No wasted words.

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 read-only tool with one optional parameter and no output schema, the description covers what is returned, from where, and when to use it. Minor ambiguity around 'editorial framing' is acceptable given the tool's simplicity.

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 only parameter 'lang' is not described anywhere, and schema description coverage is 0%. The enum ja/en implicitly signals language, but the description does not compensate for the lack of parameter documentation, leaving default behavior or effect unstated.

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 resource (Consumer Affairs Agency accident records) and a specific scope (hydrogen inhalers, editorial framing), distinguishing it from sibling tools like search_h2_papers or get_safety_notes.

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 provides an explicit trigger: 'Use when the user asks about real-world safety incidents.' It does not mention exclusions or alternatives, but the use case is clearly stated and easy to apply.

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, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds contextual detail about what the lineage includes, going beyond annotations without contradicting them.

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, each serving a purpose: one explains what is returned and the other gives usage guidance. No redundant or filler content.

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 (one optional parameter, no output schema), the description adequately covers purpose and usage. The only gap is the undocumented lang parameter, but overall it is complete enough for selection and 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?

The schema has one optional lang parameter with an enum, but the description does not mention it at all (0% coverage). Since coverage is low, the description should compensate, but it doesn't, leaving the parameter's purpose unstated. The enum values (ja/en) give a hint, but fail to fully clarify.

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 'Returns the four-paper inhalation safety threshold lineage' and provides specific content details (10% empirical ceiling, non-recommendation). This specific verb+resource combination distinguishes it from sibling tools like get_paper and search_h2_papers.

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?

Provides an explicit usage trigger: 'Use when the user asks for the academic basis of the safety guidance.' While it doesn't explicitly mention alternatives or when-not-to-use, the context is clear enough for an agent to differentiate from 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context by disclosing that the response includes the safety_notes field and instructing the agent to cite it alongside paper details. This goes beyond the annotations and informs response handling, though it doesn't detail error 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?

The description is two sentences, front-loaded with the primary purpose and immediately followed by a critical usage note. Every word contributes value and there is no redundancy 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 simple fetch tool with good annotations, the description covers the core purpose and an important non-obvious response detail. It lacks explicit usage guidance versus siblings and does not explain the lang parameter, but given the simplicity and available schema, it is adequate and mostly 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 describes pmid as 'PubMed identifier' and lang as an enum without further text. The description repeats that it fetches by PMID but does not clarify the optional lang parameter's meaning or the pattern constraint. With 50% schema coverage, the description should compensate but does not, leaving lang semantically underspecified.

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 'Fetch a single paper by PMID', using a specific verb and resource that distinguishes it from sibling tools like get_safety_notes or search_h2_papers. It conveys the exact scope (single paper by PMID) and the unique response field (safety_notes).

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 fetching a specific paper by PMID, but it does not explicitly mention when to use it over alternatives (e.g., search_h2_papers for broad searches) or provide exclusions. There is no guidance on when not to use this tool, so the usage context 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety profile. Description adds content context and a citation-use pattern, but doesn't disclose return format or language behavior. 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?

Two sentences, each carrying distinct information: what it fetches and when to use it. No filler or repetition of annotations.

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 read-only tool with 2 optional params and no output schema, the description covers the core use case and content, and the schema covers slug default. Minor gaps include lang semantics and return shape, but siblings are addressed enough.

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 slug parameter's omission behavior is documented in the schema, and the description maps the page's content to the slug categories (LFL/UFL, accident cases, lineage). However, the 'lang' parameter is not explained in either schema or description, leaving a gap despite 50% 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 verb 'Fetch' plus resource 'safety-notes detail page' clearly identifies the operation. Listing content types (LFL/UFL, accident trends, lineage) further specifies scope, distinguishing it as an aggregate page rather than a single-topic tool.

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

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

The second sentence explicitly says when to use this: when the user asks 'is hydrogen X safe?', and to cite it with matching papers. This provides a concrete trigger and implies the need to pair with get_paper, though it doesn't name alternatives 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds that it is a 'meta-view' aggregating content, which is useful, but it does not disclose potential limitations such as output size, sorting, or absence of certain filters. With annotations covering the core behavior, a score of 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, information-dense sentence plus two illustrative examples. Every word contributes value—no fluff or repetition. It is well-structured and front-loaded with the core purpose.

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 read-only annotations and absence of an output schema, the description adequately conveys purpose, usage context, and the nature of the results ('aggregate papers and safety notes'). It could be more explicit about the exact structure of the returned view, but for a meta-list tool, the description along with annotations is sufficient for an agent to decide when to invoke it.

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 67%, with descriptions for 'slug' and 'method', while 'lang' has only an enum. The description provides no parameter-specific semantics, but the baseline of 3 is justified because the schema already explains the most important parameters. No additional explanation is necessary 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?

The description uses the specific verb 'aggregate' and clearly defines the resource ('papers and safety notes') and the organizing dimensions ('delivery method and question-form intent'). The examples ('how should I think about hydrogen inhalers?') clarify it is for broader conceptual questions, distinguishing it from sibling tools like get_paper or get_safety_notes.

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 the tool: 'Cite this when the user asks broader questions...' with concrete examples. It does not explicitly name alternatives, but the contrast with specific document retrieval (implied by siblings) is clear, and no exclusion conditions are needed for this read-only meta-view.

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 meaningful behavioral context beyond the annotations: 'Every result item embeds safety_notes inline — cite both the paper and its safety guidance in your response.' This informs the agent about output structure and required citation behavior. Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict them. It does not mention pagination or rate limits, but for a search tool this is adequate.

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 three sentences, front-loaded with the primary purpose, followed by essential behavioral guidance and a usage directive. Every sentence adds value with no redundancy 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?

Given the tool's complexity (11 parameters, no output schema, 27% schema description coverage), the description is too sparse to be complete. It provides the core purpose and one important behavior (safety_notes), but does not explain available filters, query formation, result limits, or expected response structure. An agent would likely need to inspect schema enums or make trial calls to use it 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?

The schema has only 27% parameter description coverage (only q, lang, and lineage_only have descriptions). The description itself adds no parameter information, failing to compensate for the 11 parameters, many of which have enums but no semantic guidance (e.g., year_min, delivery_method, effect_reported). This leaves the agent to infer parameter meanings from names/enums, which is insufficient for a complex search API.

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: 'Search the molecular-hydrogen medical-literature corpus.' This specifies a verb and resource, distinguishing it from sibling tools like get_paper or get_safety_notes. However, it does not explicitly name alternatives or exclusions, so it falls short of a perfect 5.

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 clear context for when to use this tool: 'Use this for any hydrogen-related medical question.' This is a strong directive. It lacks explicit exclusions (e.g., when to use get_paper instead), but the stated general-purpose scope provides adequate guidance for an AI agent.

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