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

Annotations already cover read-only, idempotent, and open-world status, so the description is not carrying the safety burden. It adds genuinely non-obvious behavior: the max-50 ceiling, automatic chunking into groups of 10 to respect KEGG's API limit, and a warning that 'full' output is large at batch scale. Partial-failure handling is still undisclosed.

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?

Front-loaded with purpose and limit before any detail, and the Args block is scannable. There is minor redundancy, since the 50-ID max is stated in the intro and again in the entry_ids arg, but nothing is bloated.

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 shape needn't be explained, and the description covers scale limits, chunking, and detail tradeoffs. A bulk tool would ideally state what happens when some IDs are invalid, which is the one missing operational detail.

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 largely does: entry_ids is explained with a concrete example, an allowance to mix databases, and the 50-entry cap; detail_level explains both enum values as 'compact per-entry projection' vs 'complete flat-file parse' with the size tradeoff. The remaining gap is format/validation expectations per ID.

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 and resource (fetch multiple KEGG entries) plus the bulk scope and the 50-ID cap, so it is clearly distinguished from the single-entry siblings like get_compound_info. It never names those siblings explicitly, so the differentiation is implicit rather than stated.

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 detail_level explanation implies when to pick 'summary' vs 'full' (large GENES/sequence payloads at 50 entries), and the bulk framing implies use over single-entry lookups. But there is no explicit 'use X instead when...' routing, and no guidance on what to do with IDs that fail or span databases beyond 'can mix databases'.

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?

Goes well past the readOnly/idempotent annotations by disclosing request limits (KEGG caps at 10 IDs), that longer lists are chunked and fetched concurrently rather than dropped, that bare IDs are auto-prefixed, and that full-database conversion is very large (~700 KB). Those are exactly the operational traits an agent needs before calling.

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?

Front-loaded with the one-sentence purpose, then constraints, then per-argument detail; every section is useful given the empty schema. Slight redundancy in restating 'from the same list and the opposite side of the pair' after already showing examples keeps it from a 5.

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 need not be explained, and everything an agent must know before invoking — valid values, pairing rules, chunking, payload size — is present. Nothing material is missing for a 3-parameter 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 description coverage is 0%, so the description carries the full burden — and it does: it enumerates all valid source_db/target_db values, explains the opposite-side pairing requirement, documents entry_ids as optional with a default, and shows the auto-prefix transformation ('1956' -> 'hsa:1956'). No ambiguity remains.

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 and resource ('Convert KEGG IDs to/from external database identifiers') and immediately scopes it to one kind only, distinguishing it from every lookup/search sibling. The gene vs chemistry split is explicit, so an agent knows exactly what class of job this tool handles.

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?

Gives concrete when-to-use routing (source_db='hsa' + target_db='uniprot', chebi<->compound) plus explicit exclusions: cross-kind pairs like compound<->uniprot are rejected, and 'kegg' is not an accepted database. Also tells the agent when to omit entry_ids versus supply them.

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 safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioural context beyond them: how stripes are assigned per group, that non-matching boxes are grey, that the return includes a PNG plus a structured summary, and that the summary is authoritative over visual inspection. The refusal of 011xx/012xx maps is a concrete constraint an agent could not infer.

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?

Front-loaded with the outcome (PNG) and the key differentiator (redrawn from KGML), then structured Args covering each parameter. Dense but nearly every sentence carries decision-relevant information; the EC-matching sentence is the most convoluted and could be tightened without losing 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?

An output schema exists, yet the description still explains that the return is a PNG plus a per-group/per-box summary and tells the agent how to use it. Combined with full parameter documentation and the map-type restriction, an agent has everything needed to call this correctly on the first attempt.

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 carries the full burden and does so thoroughly: pathway_id accepts 'map00010', 'ko00010', organism maps like 'eco00010', or bare '00010'; highlight is a {label: ids} map of at most 8 groups whose ids may be KO ids in three prefixes or EC numbers in two forms, with space-separated multi-id items and a documented EC fallback via matched_by_ec. This far exceeds what the bare schema conveys.

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 and resource ('Draw a KEGG pathway map as a PNG image') and adds the distinguishing implementation detail that the map is redrawn from KGML layout rather than copied from KEGG's image. This clearly separates it from the sibling render_pathway_ascii and the various get_pathway_* retrieval 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?

Gives concrete inclusion/exclusion rules: global and overview maps (011xx, 012xx) are refused, and the highlight groups are capped at 8 (e.g. one per genome). It also instructs the agent to check the returned summary rather than describing the picture from memory. It stops short of explicitly naming render_pathway_ascii as the text alternative, so routing between the two renderers is left implicit.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context: results are returned as pairs and are capped at 100. It does not say what happens when target_db is unsupported or when an entry has no links.

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 core purpose is stated in one front-loaded sentence, followed by a compact Args block. The text is short and each line adds information; the only weak point is that it reads as a docstring rather than prose.

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 takes three parameters, has complete annotations and an output schema, and the description covers all parameter formats. It is adequate for correct invocation. The one gap is guidance on which source-to-target database pairings are valid.

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 carry the load, and it does. It documents the ID format for entry_id with three concrete examples, enumerates likely target_db values, and states the max_results cap of 100.

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 gives a specific verb and resource: find related entries in another KEGG database for a given entry. That clearly distinguishes it from siblings such as get_gene_info or search_compounds, which retrieve information about a single entity rather than link one entry to another. It does not explicitly contrast with the closest sibling, convert_identifiers, which also maps one identifier to another.

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 example IDs ('hsa:1956', 'C00002', 'K00844') and example target databases imply when the tool can be used, but there is no explicit statement of when to choose this over convert_identifiers or a get_*_info call. Nothing tells the agent which source or target database combinations are valid.

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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavior: output is deliberately bounded (level line counts, leaf column names, top two levels), and `full` includes raw_content that is TRUNCATED because hierarchies reach several megabytes. It does not describe error behavior for invalid IDs.

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?

Front-loaded with the purpose, then the rationale for the bounded summary, then a tight per-parameter block. Every sentence adds information an agent would otherwise have to discover by trial; there is no 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?

With an output schema present, return shape need not be spelled out, and the description still pre-warns about summarization and truncation. Parameter handling is complete for a two-param tool. The only gaps are failure modes on bad IDs and any explicit routing between this and sibling info tools.

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 carry the load, and it does: brite_id documents three accepted forms with concrete examples ('br:ko00001', 'ko00001'/'br08303', bare '00001'), and detail_level enumerates both values plus the consequence of 'full' and its truncation. Nothing about either parameter is left ambiguous.

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 and resource ("Get the structure of a KEGG BRITE functional hierarchy") and immediately scopes the return value to a bounded summary rather than the full tree. The reference to IDs "returned by search_brite" implicitly separates this lookup tool from the sibling search tool, though the contrast is never stated outright.

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?

Gives clear conditions for use: BRITE entries are A/B/C/D trees, not flat-file entries, so this tool returns a bounded summary and only `detail_level: full` expands it. It also explains which ID forms are acceptable, removing a common failure mode. No explicit when-not-to-use case (e.g. versus get_pathway_info) is provided.

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 the tool as read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context by explaining that detail_level controls whether the response is a compact summary or a complete flat-file parse, but it does not describe error behavior or response size implications.

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 purpose is front-loaded in the first sentence, followed by a compact Args block. Every line contributes useful information, though the formatting could be slightly tighter.

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 an output schema present and rich annotations, the description does not need to explain return values in depth. It is complete enough for correct invocation: the agent knows the required identifier format and how detail_level changes output. Minor gaps remain around invalid-ID behavior and sibling routing.

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, and it largely does. It documents both parameters, gives concrete examples for compound_id ('C00002' for ATP, 'C00031' for D-Glucose), and explains the meaning and default of detail_level.

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: 'Get detailed information for a KEGG compound entry.' This clearly distinguishes it from search tools like search_compounds, but it does not explicitly name or differentiate it from sibling tools such as get_compound_reactions.

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 through the phrase 'detailed information,' but it gives no explicit when-to-use guidance, no exclusions, and no alternatives. An agent must infer on its own when this tool is preferable to search_compounds or get_compound_reactions.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one real behavioral detail — results are capped at 100 — but says nothing about ordering, what a reaction record contains, or what happens when the cap truncates results.

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 sentence of purpose followed by a compact Args block; no filler. The Args block is somewhat redundant with the schema's parameter list but earns its place because the schema has zero description coverage.

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?

It is adequate for a simple two-parameter read tool with no output schema: the agent knows the input domain, the cap, and the safety profile from annotations. The remaining gap — the shape and ordering of returned reactions — is minor for a lookup of this kind.

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 carries the burden and does reasonably well: it explains that compound_id is a KEGG compound ID with a concrete example ('C00002') and that max_results is capped at 100 (the schema only shows a default of 100, not the cap). It does not state the default behavior when max_results is omitted.

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 gives a specific verb and resource: 'Get all reactions involving a KEGG compound.' This is clear and distinguishable from get_pathway_reactions (which is pathway-scoped) by implication, though the sibling is never named explicitly.

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 is implied by the resource framing — reach for this when you have a compound ID and want its reactions — but no explicit when-to-use or when-not guidance is given, and no alternative (search_reactions, get_pathway_reactions, get_reaction_info) is mentioned for overlapping needs.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context that the return is release information and statistics, but it does not discuss permissions, rate limits, or other behavioral constraints beyond what annotations 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?

The description is short, front-loaded, and structured with an Args section. The examples are useful rather than wasteful, though the formatting could be tightened further.

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 read-only tool with rich annotations and an output schema, the description is largely complete: it explains the purpose and gives database examples. The main remaining gap is explicit usage guidance versus sibling info tools.

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 carry parameter meaning. It does so by explaining that 'database' is a database name and giving representative examples such as 'kegg', 'pathway', 'compound', 'drug', and 'genome', though it does not enumerate all allowed values or mention the 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 states a specific verb and resource: getting release information and statistics for a KEGG database. It distinguishes the tool from entry-level siblings by focusing on database-level release/statistics, but it does not explicitly name an alternative or contrast with get_pathway_info/get_compound_info despite overlapping database names.

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 is implied by the purpose—use this when you need release/statistics for a database rather than detailed entry data. However, there is no explicit when-to-use, when-not-to-use, or alternate-tool 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real value by explaining that 'summary' is compact and 'full' is a complete flat-file parse, but says nothing about failure modes for invalid IDs, entry not found, or the size cost of 'full'.

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?

Short, front-loaded, and the Args block cleanly separates per-parameter facts. The example value is the only mildly redundant element, but it earns its place given the 0% schema coverage.

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 an output schema present, return values need no explanation, and both parameters are documented. The only remaining gap is the absent relationship to search_diseases, which would help an agent place this tool in a workflow.

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 carry the parameter burden, and it does: it names the disease_id format with a concrete example ('H00004' for colorectal cancer) and explains what each detail_level value actually means, going beyond the bare enum labels.

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 ('Get detailed information') and resource ('KEGG disease entry'), so the agent knows exactly what is returned. It does not distinguish itself from the sibling search_diseases or say this is the fetch-after-search step, so it falls short of a 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?

Usage is only implied – the presence of search_diseases as a sibling and the required disease_id suggest a search-then-fetch flow, but the description never says when to use this versus searching, nor what happens if the ID is unknown. The detail_level tradeoff is described, which is the only 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety behavior is covered. The description adds the meaningful 'summary (compact) vs full (complete flat-file parse)' distinction and the cost implication of 'complete flat-file parse', but says nothing about behavior on an invalid ID or the shape of the response.

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?

Purpose sentence is front-loaded and the Args block is compact with no wasted sentences. The nested indentation of the Args section is slightly awkward but does not cost 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?

An output schema exists, so return-value explanation is rightly omitted, and both parameters are explained. What is missing is the routing context — when to reach for this versus search_drugs or get_drug_interactions — which matters given roughly 30 sibling tools in this namespace.

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 carry the parameter burden, and it does: concrete example IDs ('D00001' aspirin, 'D00564' ibuprofen) and the semantic difference between 'summary' and 'full', the latter described as a complete flat-file parse. Only the invalid-ID/error behavior is left unexplained.

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+resource ('Get detailed information for a KEGG drug entry'), which is distinct from the sibling get_drug_interactions and search_drugs by name. It does not explicitly contrast itself with those siblings, so it stops short of 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?

Usage is only implied — the reader must infer that this is the detail-fetch step after search_drugs returns a KEGG drug ID. There is no explicit when-to-use/when-not guidance nor mention of the sibling alternatives like get_drug_interactions or search_drugs.

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 read-only, idempotent, open-world, non-destructive behavior, so the description does not need to restate safety. It usefully adds operational constraints—at most 10 drug entries and a 100-result cap—which are behavioral details beyond the annotations. It does not discuss error behavior for oversized inputs, but that is a minor 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 two short, front-loaded sentences plus a compact args block. Every sentence contributes directly to correct invocation, with no filler or 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 an output schema exists and annotations cover safety semantics, the description supplies the remaining critical input details: ID syntax, multi-ID joining, and result limits. It is nearly complete, with only minor omissions around invalid-input behavior or ordering.

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 carries the full burden and does so effectively: it gives a concrete single-ID example, the '+' joining syntax for multiple IDs, the 10-entry maximum, and the max_results cap of 100. It could go slightly further by restating the default for max_results or clarifying ordering semantics, but the essential meaning is covered.

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 ('Get drug-drug interactions') scoped to KEGG drugs, which is clearly distinct from sibling tools like get_drug_info or search_drugs. It stops short of explicitly naming an alternative or contrasting with those 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?

Usage is implied by the purpose (fetch interactions for known drug IDs), but there is no explicit when-to-use guidance, no mention of when to prefer get_drug_info or search_drugs, and no prerequisites or exclusions. This is adequate but leaves the agent to infer routing.

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 readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: detail_level controls output verbosity ('summary' compact vs 'full' complete flat-file parse), which lets an agent reason about response size and cost. It omits error/not-found behavior and rate limits, keeping it below a 5.

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 one-line purpose is front-loaded, and the Args block is terse and scannable. Slight redundancy with the schema (restating the default for detail_level), but nothing wasteful.

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 an output schema present, return values needn't be described, and the tool's complexity is low (2 params, 1 required). The description covers ID formats and verbosity control, which is everything needed to invoke it correctly; only failure modes are unaddressed.

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 carries the full burden and largely does: enzyme_id gets concrete format examples for both accepted forms ('1.1.1.1' and 'ec:1.1.1.1'), and detail_level is explained semantically with its default. It doesn't say whether prefixed/unprefixed forms are normalized or how partial EC numbers are treated.

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 and resource ('Get detailed information for a KEGG enzyme (EC number)'), which is clearly a lookup-by-ID tool as opposed to the sibling search_enzymes. It doesn't name the sibling explicitly, so it stops short of a 5, but an agent can distinguish retrieval-by-identifier from search without opening either 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?

Usage is implied through the Args block: the tool expects an EC number or prefixed ID, which tells the agent when it is applicable and implicitly routes discovery to search_enzymes. There is no explicit statement of when to prefer this over siblings or what happens with an invalid/unknown ID.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: what 'full' parses (orthologs, pathways, xrefs, references) and that include_sequence is only honored when detail_level='full' — a dependency an agent could not infer from 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 purpose sentence is front-loaded and each parameter note earns its place with no filler. The Args block style is structured and scan-friendly, though marginally more verbose than a single tight paragraph would be.

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 need not be described, annotations cover the safety profile, and all three parameters are explained including their interaction. An agent has everything needed to call this correctly on the first attempt.

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 carries the full burden and mostly succeeds: it gives the gene_id format with a worked example, defines both 'summary' and 'full' semantically rather than just repeating the enum, and states the conditional gate on include_sequence. Only the amino-acid/nucleotide sequence distinction is left slightly thin.

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 ('Get detailed information for a KEGG gene entry'), which is clearly distinct from lookup-adjacent siblings like search_genes or get_gene_orthologs. It does not explicitly name those siblings or say when to prefer them, so it stops short of full 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?

Usage is implied through the required ID format ('organism:gene', with a concrete example 'hsa:1956') and through the detail_level tradeoff, which tells an agent to start with 'summary'. However, there is no explicit 'use this instead of X' routing against search_genes or get_gene_orthologs.

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, openWorldHint and non-destructive, covering most of the behavioral profile. The description adds nothing beyond that: no indication of result shape, whether orthologs come from all organisms, or whether lookups hit a remote service with latency 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 sentence of purpose plus a single argument line, front-loaded and free of filler. The Args block is a bit ceremonial for one parameter but the example 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?

With no output schema, the description should say more about what comes back — the split between KO assignments and ortholog records, and whether orthologs are grouped by organism. A single-param read tool is simple, so this is adequate but 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 coverage is 0% and the schema only says 'Gene Id' with no type guidance, so the description's concrete format example ('hsa:1956') is genuinely load-bearing. It doesn't state the accepted ID namespaces beyond the one example, which keeps it from a 5.

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 (Get) and two specific resources (KO entries and cross-organism orthologs) scoped to a gene, which clearly separates it from get_gene_info and search_ko_entries. It doesn't explicitly name the sibling it replaces, so it stops short of 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?

There is no when-to-use guidance, no mention of when to prefer get_gene_info or get_ko_info instead, and no prerequisites or organism-scope caveats. Only the argument is documented, leaving the agent to infer selection 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 readOnly, idempotent, openWorld and non-destructive, so the safety bar is low. The description still adds real value by explaining what detail_level actually changes ('summary' compact vs 'full' complete flat-file parse), which is a payload-size tradeoff the annotations cannot convey. It does not cover invalid-ID behavior, but that is a minor gap here.

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 one-line purpose is front-loaded and the Args block is scannable with zero filler. Slight redundancy between 'detailed information' and 'full (complete flat-file parse)', but nothing that wastes real space.

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 an output schema present, the description need not explain return values, and annotations cover the safety profile. Combined with parameter documentation, an agent has everything needed to call it correctly; only the sequencing relative to search_glycans is left implicit.

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 carries the burden and does so: it gives the expected glycan_id format with a concrete example ('G00001') and spells out both enum values plus the default. The only omission is validation or error expectations for a malformed ID.

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 gives a specific verb ('Get detailed information') and resource ('a KEGG glycan entry'), which clearly separates it from the sibling search_glycans. It stops short of naming that sibling explicitly, but the get-vs-search distinction is inferable from the wording.

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 only implied: an agent can guess this is the detail-fetch step that follows search_glycans, but the description never states that or names any alternatives. No exclusions or prerequisites 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact – that 'full' performs a complete flat-file parse (i.e., a much larger, heavier response than the compact default). It says nothing about KEGG rate limits, failure modes for unknown KO IDs, or response size.

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-sentence purpose followed by a compact Args block; front-loaded and free of filler. The Args block partially restates the schema, but it earns its place because the schema itself has zero descriptions.

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 need not be described, and annotations cover safety; what remains is well served by the parameter explanations. The one meaningful gap is routing: an agent cannot tell from this description whether to search first or call directly, and sibling search_ko_entries is the obvious candidate.

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 carries the full burden and largely does: it defines ko_id with a concrete example ('K00844' for hexokinase) and explains both enum values of detail_level, including which is the default. It stops short of quantifying what 'compact' vs 'complete' actually returns.

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 and resource: 'Get detailed information for a KEGG Orthology (KO) entry,' naming the KO identifier format with an example. It is clearly distinct from lookup-ish siblings by the word 'detailed', though it never names search_ko_entries as the discovery path.

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 statement of when to use this versus search_ko_entries or batch_entry_lookup, and no prerequisite such as 'KO IDs must be obtained from search_ko_entries first.' The only usage-adjacent content is the detail_level tradeoff, which is parameter guidance rather than tool selection 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?

Annotations already cover the safety profile: read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context by explaining that `detail_level` controls a compact summary versus a complete flat-file parse, but it does not add much beyond that.

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 short and front-loaded with the core purpose, followed by compact argument notes. The Args block is efficient, though slightly redundant in style for an MCP definition.

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 read tool with an output schema and rich annotations, the description provides enough to call it correctly. The main missing element is explicit routing to `search_modules` as an alternative for discovering module IDs.

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 carry parameter meaning, and it does: `module_id` is explained with an example, and `detail_level` is described with its default and the meaning of `summary` versus `full`.

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: retrieving detailed information for a KEGG module. However, it does not explicitly distinguish this from the sibling `search_modules`, which could also involve modules, so sibling differentiation is left implicit.

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 supplies argument semantics but gives no explicit guidance on when to use this tool versus alternatives such as `search_modules` to find a module ID first. Usage is only inferable from the required `module_id` parameter.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context by stating that results are capped at 100 via max_results, though it does not elaborate on truncation or ordering.

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 action and then briefly documents the two arguments. There is no wasted text, and the example pathway ID is directly useful.

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 retrieval tool with an output schema and comprehensive annotations, the description is nearly complete. The main remaining gap is that it does not explain how results behave when the pathway has more than 100 compounds.

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 carries the burden and does document both parameters: pathway_id with a KEGG example and max_results with its 100-item cap. It adds meaningful semantics beyond the bare schema, though it could clarify the meaning of 'pairs' and valid max_results bounds.

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: 'Get all compounds (metabolites) associated with a KEGG pathway.' This clearly distinguishes it from pathway siblings such as get_pathway_genes, get_pathway_reactions, and get_pathway_info.

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 pathway association implies when to use it, but the description does not explicitly state when to choose this over alternatives like search_compounds or get_compound_info. There is clear contextual scoping, but no explicit usage guidance 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 readOnly=true, idempotent=true, openWorld=true, and non-destructive. The description adds useful behavioral context beyond annotations: the KEGG gene link API does not support reference pathways, and max_results is capped at 100. It does not describe pagination or return shape, but an output schema exists.

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 short and front-loaded with the purpose, then structured into an Args block. Every line is relevant, though the phrase is slightly formal rather than conversational.

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 simple two-parameter schema, existing output schema, and rich annotations, the description supplies the key context an agent needs: correct ID format and unsupported reference pathways. It stops short of explaining what happens when max_results truncates results, but that is a minor omission.

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 carry parameter meaning. It does well: pathway_id is explained with examples ('hsa00010', 'pae00350') and a critical restriction about reference pathways, while max_results is explained as a cap of 100. Minor gaps remain around default behavior and whether max_results truncates silently.

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: 'Get all genes associated with a KEGG pathway.' It is clearly distinguishable from siblings like get_pathway_info, get_pathway_compounds, and get_pathway_reactions, which return different entity types for a pathway.

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 a concrete usage constraint: organism-specific IDs are required and reference 'map*' pathways are not supported. It does not explicitly compare against search_genes or get_gene_info, but the tool's niche is clear from the purpose statement.

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 safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely useful behavior beyond that: it explains that 'full' performs a complete flat-file parse and returns all linked genes, compounds, reactions, references and xrefs, which signals response size and payload breadth.

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 purpose sentence is front-loaded and the Args block is tight with no filler. The docstring-style formatting is slightly verbose for two parameters but every line carries 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?

With an output schema present and all parameters explained, an agent has enough to invoke this correctly. The remaining gap is routing guidance relative to the pathway-specific siblings and what 'summary' actually contains.

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 carries the burden — and it does, giving pathway_id examples ('hsa00010', 'map00010') and defining both detail_level values plus the 'summary' default. It stops short of explaining the hsa vs map prefix semantics, which matters for organism-specific vs reference pathways.

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?

Specific verb+resource ("Get detailed information for a KEGG pathway") with a named identifier format. It does not, however, distinguish itself from the many pathway-scoped siblings (get_pathway_genes, get_pathway_compounds, get_pathway_reactions), which return subsets of what 'full' detail returns.

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 detail_level explanation implies usage ('summary' for compact, 'full' for everything), but there is no explicit when-to-use guidance and no mention of the alternative tools that return pathway genes/compounds/reactions individually or of search_pathways for discovery.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful cap of 100 results, but does not explain truncation behavior beyond that cap or whether results are complete or sampled.

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 short and front-loaded, with the core action in the first sentence and parameter details in a compact Args block. Every sentence adds value.

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 an output schema present and annotations covering safety, the description need not explain return values. It covers both parameters and the result cap, leaving only alternative-tool routing as a minor gap for this simple retrieval 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 description coverage is 0%, so the description must compensate. It documents both parameters: pathway_id with a concrete KEGG ID example and max_results with the 100 cap. The term 'pairs' is slightly ambiguous, but overall it meaningfully supplements the bare 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 specific verb and resource: 'Get all reactions in a KEGG pathway.' This clearly distinguishes it from pathway siblings like get_pathway_genes and get_pathway_compounds by resource type, though it does not explicitly differentiate it from search_reactions.

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 is implied by the name and resource scope, but there is no explicit guidance on when to use this versus search_reactions or get_reaction_info. No alternatives or exclusions are named.

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 safety and idempotency, but the description adds useful behavioral context by explaining that detail_level controls output depth: 'summary' is compact and 'full' is a complete flat-file parse. It does not discuss rate limits or error behavior, but those are not critical for this simple read-only lookup.

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 short, front-loaded, and structured as a clear purpose statement followed by parameter documentation. Every sentence and example 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 two-parameter read-only lookup with annotations and an output schema, the description is largely complete. The main gap is the lack of explicit routing guidance versus search or pathway-based sibling tools.

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, and it does: reaction_id is explained with an example format, and detail_level is documented with its default and the meaning of each enum value. It could add stricter ID-format guidance, but the key semantics are covered.

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: 'Get detailed information for a KEGG reaction.' It clearly identifies the tool as a detail-fetch operation by reaction ID, though it does not explicitly distinguish itself from sibling tools like search_reactions or get_pathway_reactions.

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 is only implied through the required reaction_id parameter and detail_level choices. The description does not state when to use this tool instead of search_reactions or get_pathway_reactions, nor does it mention prerequisites such as needing an existing KEGG reaction ID.

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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the corpus is ~12,000 organisms, an empty query silently returns only the first `max_results`, and `max_results` is capped at 100.

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?

Front-loaded with the purpose, then the filtering rationale, then per-argument detail — the reader gets the key decision information in the first two sentences. Minor redundancy between the prose hint and the Args block, but nothing wasteful.

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 and annotations are rich, so the description needn't explain return shapes. The only gap is that "the first `max_results` organisms" leaves the sort/ordering of that slice unspecified, which matters when the result is truncated.

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% (only bare titles), so the description carries the full burden and does: `query` is a case-insensitive substring filter on code or name with examples ('Bacillus', 'hsa') and an explicit empty-string default; `max_results` is documented with its default and an undocumented-in-schema cap of 100.

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 and resource ("List organisms available in KEGG") and specifies the returned content (3-4 letter codes and names). No sibling tool in the list enumerates organisms, so the resource is unambiguous within the toolset.

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?

Gives a clear usage rule: because KEGG has ~12,000 organisms, pass `query` to filter rather than paging through everything. It does not name explicit alternatives or when-not-to-use cases, but the intended workflow is clear without 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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered structurally. The description adds real value beyond that: the map* KGML limitation and the grid-only scope of max_height. It does not disclose failure behavior for invalid or unsupported pathway IDs, or any cost/limits on rendering.

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?

Front-loaded with the one-line purpose, then a two-bullet mode comparison, then a compact Args block. Every line adds information, though the Args block partially overlaps the schema's defaults and could be trimmed slightly.

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-value description is not required. With 4 params, 0% schema coverage and a rich enum/mode dimension, the description covers what an agent needs to call it correctly; minor gaps are error handling and whether the rendered output is paged or truncated by max_width/max_height beyond the stated bounds.

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 carries the full burden and does: it explains pathway_id format with a concrete example ('hsa00010'), the biological distinction between organism-specific and map* IDs, the enum meaning of style, and numeric ranges for max_width (40-200) and max_height (20-80) that the schema itself lacks.

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 and resource ('Render a KEGG pathway as ASCII text') plus the intended consumer ('optimized for LLM consumption'). Among the siblings, which are all data-lookup tools (get_pathway_info, get_pathway_genes, search_pathways), this is clearly the only visualization/rendering tool, so differentiation is implicit but 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?

Gives explicit selection criteria between the two modes ('chain' best for reaction sequences, 'grid' best for spatial relationships) and warns that pathway_id must be organism-specific because reference map* pathways have limited KGML. It does not explicitly contrast this tool with get_pathway_info/get_pathway_reactions, which would be the natural 'when not to use' 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the useful cap of 100 results but does not describe pagination, result ordering, or other behavioral details beyond that cap.

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 short, front-loaded with the core action, and uses an Args block efficiently. Every sentence contributes either the purpose or parameter clarification.

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 need not be explained, and annotations cover safety and idempotency. The description covers both parameters adequately, though it could better distinguish search_brite from get_brite_info for complete task context.

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, and it does define both parameters. The query examples and the max_results cap of 100 add meaningful semantics beyond the bare schema, though the default value of 25 is left to 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 specific verb and resource: search KEGG BRITE functional hierarchy databases. This clearly distinguishes it from siblings such as get_brite_info, but it does not explicitly name that sibling or clarify search-vs-detail boundaries.

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 is implied by the query examples such as 'KEGG pathway', 'transporter', and 'ribosome', which show what to search for. However, there is no explicit guidance on when to use this tool instead of get_brite_info or other search 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds only the useful 100-result cap and defaults; it says nothing about pagination, result ordering, or remote/network 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?

One lead sentence plus a compact Args block; the core action is front-loaded and nothing is padded. The terseness of the enum descriptions costs a little 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?

An output schema exists so return shape needn't be described, and all three params are addressed. The residual gap is the undocumented 'nop' mode and unit/format specifics for mass and formula searches.

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 carries the load. It documents all three parameters and the enum's intent, which is solid, but leaves 'nop' undefined and doesn't clarify mass units or formula syntax.

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 and resource ('Search KEGG compounds') and the axes it searches on (name or chemical property). This distinguishes it from retrieval siblings like get_compound_info, though it doesn't name them explicitly.

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 search_type enumeration implies when to use each mode and query's parenthetical gives formats, but there is no explicit guidance on choosing exact_mass vs mol_weight, no explanation of 'nop', and no mention of when to prefer get_compound_info over searching.

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 this as a safe, idempotent, non-destructive open-world read operation. The description adds useful behavioral detail beyond annotations, notably that results are capped at 100 and that matching is by disease name or keyword.

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 operation and then briefly explains both arguments. There is no redundant or wasted 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?

For a simple two-parameter search tool, the description covers the operation and parameter semantics sufficiently. Return-value details are not needed because an output schema exists, and annotations already supply the safety and openness profile.

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 carry parameter meaning; it does document both parameters, including examples for query and the cap for max_results. It could be stronger by noting case behavior or default behavior, but it adequately compensates for the schema 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 states a specific verb and resource: searching KEGG diseases by name or keyword. It is clear enough to distinguish from detail-retrieval siblings like get_disease_info, but it does not explicitly name or contrast with that sibling.

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 search-oriented wording implies when to use this tool, and the query examples make the intended input clear. However, it gives no explicit when-to-use versus get_disease_info guidance or when-not-to-use conditions.

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 read-only, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds useful constraints such as the default search_type and the 100-result cap, though it does not discuss pagination or result completeness.

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-loads the core purpose, and then uses a short Args block for parameter details. There is no redundant 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?

An output schema exists, so return values need not be described, and annotations cover the behavioral safety profile. The remaining gap is mainly explicit routing guidance versus sibling tools and clearer semantics for the mass-related search modes.

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 carry parameter meaning. It explains query, all four search_type values with a default, and max_results with a cap, but leaves the exact_mass versus mol_weight distinction and expected mass format somewhat unclear.

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: search KEGG drugs by name, formula, or molecular weight. It clearly distinguishes a search operation from detail-oriented siblings such as get_drug_info or get_drug_interactions.

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 lists the supported search modes and defaults, which implies when the tool is appropriate. However, it does not explicitly say when to use this instead of get_drug_info, search_compounds, or other drug-related 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds a real behavioral constraint the annotations lack: results are capped at 100. It says nothing about truncation behavior, pagination, or ordering, which is a moderate gap but not a serious one for a read-only search.

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 core purpose is front-loaded in one sentence, and the Args block is compact with no filler. Slight redundancy in restating parameter names the schema already exposes, but each line adds format detail rather than repeating types.

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 two-parameter read-only search with an output schema available, the description covers both parameters, the cap behavior, and accepted query formats. What is missing is routing guidance relative to get_enzyme_info, which is the main remaining 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%, so the description carries the full burden and does so: it defines 'query' as an EC number or enzyme name with concrete examples ('1.1.1.1', 'kinase', 'oxidase') and states that max_results is capped at 100. It omits the default of 25, which the schema supplies, so the gap is minor.

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 and resource ('Search KEGG enzymes') plus the two lookup keys (EC number or name), which is enough to distinguish it from get_enzyme_info by implication. It never names the sibling explicitly, so discrimination relies on the agent inferring search-vs-detail semantics.

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 a discovery-then-detail workflow (search here, then get_enzyme_info), but never says so. There are no explicit when-to-use, when-not-to-use, or alternative-routing statements despite several plausible siblings (search_genes, search_compounds, get_enzyme_info).

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, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful constraint that max_results is capped at 100, but says nothing about permissions, result ordering, or matching behavior (exact vs substring), which materially affect how a search is issued.

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?

Front-loaded with a one-line purpose, then a compact Args block with no filler. Some of the Args lines restate schema property titles, but each carries additional semantics, so the space is largely earned.

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 need not be described. All three parameters are explained and the organism scoping is clear, leaving only minor gaps: the default organism when omitted and how this differs from the ID-based gene lookups.

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 carry the load, and it does: it explains all three parameters, clarifies that query covers gene name, symbol, or description, and gives concrete organism codes ('hsa', 'mmu', 'eco'). It also adds a cap of 100 on max_results that is absent from the schema, though it never states the default (hsa / 25) that the schema implies.

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?

Names a specific verb and resource ('Search for genes') and scopes it to a KEGG organism database, so the agent knows exactly what is being queried. It does not distinguish itself from siblings such as get_gene_info, search_ko_entries, or get_gene_orthologs, leaving selection partly to inference.

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 is only implied: the word 'search' plus a free-text query term suggests this is for discovery when IDs are unknown, with organism_code scoping the space. There is no explicit statement of when to prefer this over get_gene_info (fetch by ID) or get_gene_orthologs, and no exclusions or prerequisites 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that max_results is capped at 100.

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 short, front-loaded with the core purpose, and then documents the arguments efficiently. Every sentence contributes useful 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?

With annotations and an output schema present, the definition covers the main requirements for a search operation: what is searched, how to query, and the result cap. Minor gaps remain around matching behavior and ordering, but nothing essential 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 must carry parameter meaning. It explains that query accepts a glycan name or composition with useful examples, and that max_results is capped at 100, covering both parameters well though without exhaustive syntax details.

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 gives a specific verb and resource: search the KEGG glycan database by keyword or composition. It is clearly a search tool rather than a detail-fetch tool like get_glycan_info, though it does not explicitly name sibling alternatives.

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 is implied by 'search ... by keyword or composition', but there is no explicit when-to-use guidance, exclusions, or comparison to alternatives such as get_glycan_info for detailed records. It is adequate but leaves routing 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds a useful cap of 100 results, but does not discuss ranking, pagination, or return behavior beyond what annotations and output schema 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?

The description is front-loaded with the main purpose and then efficiently documents the two arguments. There is no unnecessary text, and the examples and cap are directly useful.

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 rich annotations and an output schema present, the description is nearly complete for a two-parameter search tool. The main remaining gap is explicit routing guidance versus get_ko_info or other KO-related tools.

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 carry parameter meaning. It does this well for both parameters: query is defined as a gene-function keyword with examples, and max_results is explained as a capped result limit.

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: search KEGG Orthology (KO) entries by keyword. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as get_ko_info or other search_* 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 query examples imply that this is a keyword search for gene functions, but the description does not state when to use this tool instead of get_ko_info or related search tools. Usage is implied rather than explicitly guided.

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 read-only, idempotent, non-destructive, open-world behavior, so the safety burden is covered. The description adds one genuinely useful behavioral fact not present in structured data: results are capped at 100. It says nothing about matching semantics (term vs. ID matching, substring vs. fuzzy) or behavior on empty results.

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?

Short and front-loaded, with the purpose in the first sentence and parameters in a compact Args block. Minor waste from the Args formatting duplicating schema field names, but nothing extraneous.

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 need not be explained, and the simple two-parameter read operation is largely covered. Still missing the relationship to get_module_info and any note on what the query actually matches against (module names, IDs, or pathway blocks), which matters for a keyword search 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 description coverage is 0%, so the description must carry parameter meaning, and it does: query is defined as a module name or pathway block with concrete examples ('glycolysis', 'TCA cycle'), and max_results is explained along with its hard cap of 100, which the schema's default of 25 does not convey.

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+resource ("Search KEGG modules") which is unambiguous and clearly distinct from the get_* siblings such as get_module_info. However, it does not distinguish itself from the many other search_* siblings (search_pathways, search_ko_entries, search_genes), leaving scope at the KEGG module database to be inferred from the name alone.

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 discovery usage by describing the query as a keyword, but gives no explicit when-to-use or when-not guidance and never names the natural follow-up (get_module_info) for retrieving full details. An agent must infer the search-then-fetch workflow from the sibling list.

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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds two pieces of real behavioral context the annotations lack: results are capped at 100 regardless of max_results, and organism_code='map' yields reference rather than organism-specific pathways. It doesn't disclose matching field or case/paging 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?

One front-loaded purpose sentence followed by an Args block; no filler. Because structured coverage is 0%, restating the parameters with added semantics is justified rather than redundant, though the block could fold into prose more tightly.

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 need not be explained, and all three parameters are addressed. Remaining gaps are minor: keyword matching scope, default values (25, map), and what to do if results exceed the 100 cap.

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 carry all param meaning, and it largely does: example query terms, the 3-4 letter organism code format with 'hsa'/'mmu' examples and the 'map' special value, and the 100-result ceiling on max_results. It omits the default values and doesn't say which fields the keyword is matched against.

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 ('search') and resource ('KEGG pathways') with the matching mode ('by keyword'), which cleanly separates it from search_reactions, search_compounds and search_brite. It never names a sibling or says explicitly that get_pathway_info is the follow-up for a hit, so it stops short of full 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?

Usage is only implied: an agent can infer this is the entry point before calling get_pathway_info / get_pathway_genes, but nothing states when to prefer it or when not. The 'map' note gives a hint about reference pathways, but no explicit selection criteria between 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that max_results is capped at 100, with no further behavioral details such as ordering, pagination, or external-service 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 short and front-loaded, with the purpose stated first and parameter meanings following in a compact Args block. It is appropriately sized, though the Args formatting is slightly mechanical rather than fully narrative.

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 search tool with rich annotations and an output schema, the description is sufficiently complete. It does not need to explain return values because an output schema exists, and it covers the key input semantics and result cap.

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 carry parameter meaning. It documents both parameters: query as a reaction name or description, and max_results as capped at 100. It does not mention the default value of 25, but otherwise compensates well for the schema 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 states a specific verb and resource: "Search KEGG reactions by keyword." This clearly distinguishes keyword-based reaction search from sibling detail tools like get_reaction_info, though it does not explicitly name the alternative.

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 keyword search via "Search KEGG reactions by keyword" and defines the query as a reaction name or description. However, it gives no explicit guidance on when to use this tool versus get_reaction_info, get_pathway_reactions, or other search tools.

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