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

Annotations indicate readOnlyHint and openWorldHint. The description adds important context: invalid accessions are skipped (not aborting), and only the first 100 valid accessions are fetched. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with main purpose, followed by usage guidance and behavioral notes. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (batch operation, two parameters, output schema exists), the description adequately covers usage scenario, failure behavior, and parameter details. It is complete for agent understanding.

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 100%, so baseline is 3. The description adds value by clarifying that invalid accessions are skipped and limiting to first 100, and mentioning response_format options. Slightly above baseline.

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

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

The description clearly states 'Fetch multiple entries in a single call', uses a specific verb and resource, and explicitly distinguishes this tool from the sibling 'uniprot_get_entry' by highlighting the batch efficiency.

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

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

The description explicitly advises using this tool instead of repeated 'uniprot_get_entry' calls when a list of accessions is already available, and it explains the behavior with invalid accessions (skipped, not abort).

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 provide readOnlyHint and openWorldHint. The description adds crucial detail: 'Pure-Python — no additional external API call beyond the FASTA fetch' and specifies standard methods (Lehninger pK, Kyte-Doolittle, Pace 1995 formula), fully disclosing external dependencies and computation approach.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose and followed by methodology. Every sentence adds value with no redundancy or fluff.

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 presence of an output schema (context indicates has output schema=true), the description sufficiently explains inputs (accession, response_format) and outputs (list of properties). No gaps remain for an agent to use this tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add parameter-level details beyond the schema, but it explains the overall computation context. No extra value for parameters beyond what schema already provides.

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

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

The description clearly states 'Derived sequence chemistry for a UniProt entry' and enumerates specific properties (molecular weight, pI, GRAVY, aromaticity, net charge, extinction coefficient, composition). This uniquely distinguishes it from sibling tools that retrieve raw data, sequences, or features.

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

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

The description implies usage for computing physical/chemical properties from the canonical sequence. While it does not explicitly state when to use this instead of siblings like uniprot_get_entry, the context and enumerated properties make the use case clear.

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

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

Annotations (readOnlyHint, openWorldHint) cover safety. Description adds 1-indexed, response_format options, and list of returned feature types, enriching beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, efficient. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists and annotations are rich, description fully covers what, why, and how to use the tool.

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

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

Schema has 100% coverage; description repeats some details (1-indexed, markdown default) but adds no new parameter semantics beyond 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?

Clear verb ('List') and specific resource ('UniProt feature at position'). Distinguishes from sibling tools like uniprot_get_features which return full feature sets, making purpose evident.

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

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

Provides concrete example ('residue 175 of TP53') and variant-effect use case. Lacks explicit contrast with siblings or when-not-to-use, but context is sufficient.

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

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

Annotations already indicate readOnlyHint and openWorldHint, so the bar is lower. The description adds that this is a filtered view over the feature array, providing domain context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences are concise and front-loaded with the core purpose, followed by context. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description does not need to detail return values. It provides sufficient context about the data type (residue-level chemistry) and use cases.

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

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

Schema coverage is 100% and the description does not add extra meaning to the parameters beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states that the tool returns active sites, binding sites, metal-binding residues, and DNA-binding regions, which is specific and distinct from sibling tools like uniprot_get_features by highlighting it as a filtered view over the entry's feature array.

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

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

The description provides context for when to use this tool by mentioning its role in enzyme drug-design and antibiotic target-validation workflows, but does not explicitly state when not to use it or list alternatives.

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?

Discloses that the tool calls a third-party API (https://alphafold.ebi.ac.uk) and references privacy implications in PRIVACY.md. The annotations (readOnlyHint, openWorldHint) are consistent. Description adds significant behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Compact 5-sentence description with clear front-loading: purpose, output details, usage guidance, and third-party disclosure. Every sentence serves a purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description sufficiently covers all relevant aspects: purpose, output content, usage scenarios, and third-party sourcing. No gaps remain for an AI agent to make an informed invocation decision.

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 already describes both parameters clearly (100% coverage). The description adds value by explaining the output bands and their meaning, which helps in understanding the response_format parameter's utility. However, it doesn't add new semantic information to the parameters themselves.

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

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

The description clearly states it fetches per-residue confidence (pLDDT) summary for an entry's AlphaFold model, not just its existence. It distinguishes from the sibling tool uniprot_resolve_alphafold by specifying that the latter only provides model ID and viewer link.

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

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

Explicitly advises to call uniprot_resolve_alphafold first if only the model ID and viewer link are needed. Provides concrete interpretation of the output bands (e.g., '95% very high' is publication-grade) to guide decision-making.

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 confirm read-only and open-world semantics. The description adds detail on returned fields (title, authors, journal, year, volume, pages, cross-references), providing useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, front-loaded with key information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple fetch tool, the description is complete: it states the input, output summary, and usage context. Output schema exists, so return values need not be detailed.

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 100%, so the baseline is 3. The description does not add new meaning to parameters beyond what the schema already provides.

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

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

The description clearly states 'Fetch a UniProt citation record by ID' with example (PubMed ID). It distinguishes from sibling tools like uniprot_search_citations (search) and uniprot_get_publications (different resource).

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 specifies when to use: given a specific citation ID. It implies the alternative tool uniprot_search_citations for searching, but does not explicitly state when not to use.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds context about output formats (markdown with provenance footer, JSON payload) and the scope of data (every external-database cross-reference). It does not contradict annotations, and the additional behavioral details are valuable but not extensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no waste. The first sentence states the core function, and the second provides usage guidance and alternatives. It is front-loaded and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given full schema coverage, annotations (readOnlyHint, openWorldHint), an output schema (exists), and clear guidelines for use, the description is complete. It tells exactly what the tool does, when to use it, and refers to richer alternatives. No missing information for an AI agent to select and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the purpose of the database parameter (filtering) with examples, clarifying the accession parameter format with specific examples (P04637, P38398) and case-sensitivity, and detailing the response_format options (markdown vs JSON with descriptions). This goes beyond the schema descriptions.

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

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

The description clearly states the tool lists all external-database cross-references for a UniProt entry, with optional filtering by database. It distinguishes itself from dedicated richer tools for common databases like PDB, AlphaFold, InterPro, and ChEMBL, making the purpose highly specific and unambiguous.

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

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

The description explicitly tells when to use this tool (for databases not covered by dedicated tools or to see the full set) and when not to (for common databases where dedicated tools provide richer details). It names specific alternative tools, providing excellent 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 declare readOnlyHint and openWorldHint, and the description adds behavioral context: explains empty results do not imply disease irrelevance, and describes the provenance (literature-anchored). No contradictions; description enhances understanding beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, front-loading the core purpose and key details (returned fields, clinical relevance). Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, description does not need to explain return structure. Covers tool purpose, usage guidance, behavioral nuances, and parameter context comprehensively. Context signals indicate no gaps.

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

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

Schema coverage is 100% with two parameters adequately described in the input schema. The description adds no additional semantic meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

Clearly states the tool returns structured disease associations for a UniProt entry, listing specific fields (name, acronym, UniProt disease ID, OMIM cross-reference, etc.). Distinguishes from sibling tools by emphasizing it is UniProt-curated versus raw cross-references.

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

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

Explicitly states the tool is critical for clinical interpretation and clarifies what differentiates it from raw cross-references. Provides guidance on when not to rely on empty results, directing to alternative sources like Open Targets, OMIM, and DisGeNET for population-level evidence.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the behavior is safe. The description adds value by detailing the specific return fields (function, gene, etc.), and it does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and examples, no wasted words. Every sentence contributes essential 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?

Given the tool's moderate complexity, the description adequately covers what the tool does and what it returns. An output schema exists, so return format details are not needed in the description.

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

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

With 100% schema coverage, the baseline is 3. The description adds meaning by explaining accession example and acceptance of both reviewed/unreviewed. It also clarifies the response_format options (markdown default, human-readable; json machine-parseable) beyond the schema.

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

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

Description clearly states 'Fetch a UniProt protein entry by accession' with concrete examples (P04637, P38398) and lists specific returned data (function, gene, organism, disease associations, cross-references). This distinguishes it from sibling tools like uniprot_get_sequence or uniprot_batch_entries.

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

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

The description does not explicitly guide when to use this tool versus siblings (e.g., single entry vs. batch, overview vs. specific feature tools). The context implies it's for a comprehensive single entry fetch, but no alternatives or when-not-to-use are mentioned.

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

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

The description goes beyond annotations (readOnlyHint, openWorldHint) by detailing the scoring algorithm, classification scheme, and output structure. It explains what a score of 100 vs. 10 means, providing actionable behavioral insights for downstream agents.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 sentences) and front-loaded with the core purpose. It efficiently covers why, how, and the output format without extraneous words. Every sentence contributes meaningful 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?

Given the presence of an output schema, the description adequately explains the tool's behavior, scoring rationale, and output blocks (evidence_confidence, evidence_counts). It provides sufficient context for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by providing concrete examples (accession like 'P04637'), clarifying case-sensitivity for accessions, and elaborating on response_format options (markdown with provenance footer vs. JSON). These details enhance understanding beyond the schema.

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

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

The description clearly states the tool summarizes and grades ECO codes for a UniProt entry, counts evidence code usage, classifies into experimental/manual/automatic, and outputs a 0-100 confidence score. This specific verb-resource combination distinguishes it from sibling tools like uniprot_get_features or uniprot_get_entry.

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

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

The description explicitly calls out the critical use case: distinguishing 'wet-lab confirmed' from 'inferred by similarity'. This provides clear context for when to use the tool, though it does not explicitly mention when not to use it or name specific alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's behavioral contribution is limited. It adds that the tool returns a 'full, unfiltered' array and optionally narrowed, which is consistent. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action and scope, then provides alternatives. No wasted words. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 100% schema coverage, existing annotations, and an output schema, the description fully covers what the tool does, its optional narrowing, and how it differs from sibling tools. No gaps.

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

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

Schema coverage is 100%, baseline 3. Description adds value beyond schema by explaining 'leave empty to return every feature' for feature_types and noting that 'any other value is rejected' for response_format. This contextualizes the parameters.

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?

Clearly states 'Return the full, unfiltered feature array for an entry' and lists domains, binding sites, PTMs, etc. Distinguishes from siblings by naming specific alternative tools for narrower views.

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

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

Explicitly states when to use (full feature array) and when not to (use uniprot_features_at_position for residue-specific view, or dedicated tools for curated subsets). Provides both usage context and 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 declare readOnlyHint and openWorldHint, and the description ('Get GO annotations') aligns with read-only behavior. However, no additional behavioral traits (e.g., data freshness, rate limits) are disclosed 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 a single sentence that is technically concise but borderline under-specified. It lacks structure and does not elaborate on the output or grouping, making it less effective for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters and an output schema, the description omits key context such as that the output is a grouped list of GO terms by aspect, and that it works for a single accession. This leaves the agent with an incomplete mental model of the tool's behavior.

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?

Input schema covers 100% of parameters with detailed descriptions, so the description adds no extra meaning. Baseline of 3 is appropriate as it neither harms nor helps beyond the schema.

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

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

Description states 'Get GO annotations grouped by aspect' – specific verb and resource with a distinctive grouping behavior that helps differentiate from other UniProt tools that also retrieve GO annotations.

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

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

No guidance provided on when to use this tool versus alternatives like uniprot_get_entry or uniprot_get_features; the agent receives no contextual clues for selection.

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

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

In addition to readOnlyHint and openWorldHint annotations, the description specifies that output can be markdown or JSON, adding behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and example, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description covers all necessary information for a fetch-by-ID tool.

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

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

Schema coverage is 100%, but description adds meaningful detail: example for keyword_id and explanation of response_format options including rejection of other values.

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

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

The description clearly states the tool fetches a UniProt keyword by ID, provides an example, and lists returned data fields. This distinguishes it from sibling 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?

No explicit guidance on when to use this vs. alternatives like search_keywords. Usage is implied but not clarified.

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

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

Annotations already declare readOnlyHint and openWorldHint. Description adds context that it's a pre-filtered view but doesn't disclose additional behavioral traits. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and usage, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Has output schema, so return values are covered. Description explains feature types, related tools, and use cases. Complete for this tool.

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

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

Schema coverage is 100%, so the schema already documents both parameters. Description does not add extra meaning beyond what's in the schema.

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

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

The description clearly states it returns maturation and processing features (signal peptide, propeptide, etc.) and distinguishes it from related tools like uniprot_get_ptms and uniprot_get_features.

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

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

Explicitly tells when to use (for cleavage/targeting) and when not (for PTMs, use uniprot_get_ptms). Also provides use cases like therapeutic-protein engineering and pathogen-secretion-system analysis.

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

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

Annotations already declare readOnlyHint and openWorldHint; description adds specific return fields (organism, taxonomy, counts, etc.), providing useful context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with main purpose, no unnecessary 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?

Lists return fields; output schema exists for detailed structure. Could mention error handling for invalid ID, but overall sufficient for a fetch 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?

Adds meaning for proteome_id with example and prefix note; response_format is already well-documented in schema. Schema coverage is 100%, so description adds moderate value.

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

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

Description clearly states it fetches a UniProt proteome by UP ID with a specific example, distinguishing it from sibling tools like uniprot_get_entry or uniprot_search_proteomes.

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?

Implies usage via 'Fetch a UniProt proteome by UP ID', but does not explicitly state when to use versus alternatives or provide exclusion criteria.

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

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

The description adds valuable behavioral context beyond annotations (readOnlyHint, openWorldHint), such as explaining the functional importance of PTMs and acknowledging that empty results are an honest case with pointers to external databases. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the list of PTM types. While every sentence adds value, it could be slightly more concise. Overall, it is efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to detail return values. It fully covers the tool's purpose, usage context, sibling differentiation, and edge cases (empty results), making it highly complete for a lookup 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 100%, with both parameters already fully described in the input schema. The tool description does not add new parameter information, but the provided schema descriptions are clear and complete, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns post-translational modification features (modified residues, glycosylation sites, etc.) and explicitly distinguishes from the sibling tool uniprot_get_processing_features for cleavage/targeting features. It uses specific verbs and resource types.

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

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

The description provides explicit guidance on when to use this tool versus alternatives, including directing users to uniprot_get_processing_features for different feature types. It also advises on empty results by pointing to mass-spec databases like PhosphoSitePlus and GlyConnect.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool is a pure composition with no additional HTTP calls, and lists the specific fields returned (e.g., reference position annotations). This provides useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded paragraph that efficiently conveys all necessary information without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the return values are already documented. The description covers the key content (fields, reference position examples), making it complete for a list operation.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds minimal extra detail beyond restating the schema's description. Baseline 3 is appropriate.

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

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

The description clearly states it lists publications UniProt cites on an entry, with specific fields like PubMed IDs, DOIs, titles, authors, etc. It distinguishes from siblings by being a direct retrieval for a given entry, not a search or other operation.

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 by stating it's a composition over the entry's references block with no extra HTTP call, suggesting efficiency. However, it does not explicitly state when to use vs alternatives or provide 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?

Discloses that output is always markdown/plain-text FASTA and that there is no response_format parameter. Consistent with readOnlyHint and openWorldHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that front-load the core action, then provide usage guidance and a relevant detail about the output format. No superfluous 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?

Covers purpose, usage context, output format, and parameter behavior. With an output schema present, explanation of return values is unnecessary.

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

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

The only parameter (accession) is well-described in the input schema. The description adds value by clarifying the absence of other parameters (no response_format), so it goes beyond baseline 3.

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?

Clearly states 'Fetch the canonical protein sequence in FASTA format', specifying the verb, resource, and output format. Distinguishes from sibling uniprot_compute_properties by contrasting use cases.

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

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

Explicitly says 'Use this when you need the raw residue string itself' and advises calling uniprot_compute_properties for derived properties, providing clear differentiation among 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 indicate readOnlyHint=true and openWorldHint=true. Description adds useful context about the returned fields (name, definition, category, GO cross-refs, hierarchy), going beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first line states action with examples, second line lists returned content. No filler, front-loaded for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (fetch by ID), output schema exists, and annotations are present, the description fully covers purpose, parameters, and output. No gaps.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the location_id format with examples and clarifying response_format options ('markdown' or 'json'), exceeding schema 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?

Description clearly states 'Fetch a UniProt subcellular-location term by ID', provides specific ID examples (SL-0039, SL-0086, SL-0191), and lists returned data (name, definition, etc.). This distinguishes it from the sibling search tool.

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

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

Description implies usage when you have a specific ID, but does not explicitly state when to use vs alternatives like uniprot_search_subcellular_locations. No exclusion criteria are mentioned.

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 indicate readOnlyHint=true (no mutation) and openWorldHint=true (results may vary). The description aligns with these, stating it returns data (sequence, checksums, etc.) and provides context about UniParc's non-redundant nature. No contradiction, and description adds useful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences. The first sentence delivers the primary action and return value, and the second provides context and usage guidance. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, one required) and the presence of an output schema, the description covers purpose, usage conditions, return content, and sibling differentiation. It is complete for an AI agent to select and invoke correctly.

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

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

Schema coverage is 100% (both parameters have descriptions). The description adds extra meaning beyond the schema by explaining what the returned data includes (sequence, MD5/CRC64, cross-reference counts, etc.), and it reinforces the UPI format. While the schema is sufficient, the description enriches understanding.

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 ('Fetch') and resource ('UniParc sequence-archive record'), clearly states the input requirement (known UPI), and distinguishes from sibling tools by explaining when to use a search tool instead ('Don't have a UPI yet? Use uniprot_search_uniparc').

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

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

The description explicitly states when to use this tool (when you have a UPI) and when not to (if you don't have a UPI, use uniprot_search_uniparc). It also explains the uniqueness of UniParc records, reinforcing the rationale for this tool.

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 declare readOnlyHint and openWorldHint. The description adds behavioral context by listing the returned fields (representative member, member list, common taxon, last-updated date) and explaining the meaning of cluster prefixes. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one sentence for the action, inline examples, and a bullet list of returned fields. No redundant information, every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description appropriately omits return value details. It covers all necessary context for a simple fetch-by-ID tool: valid IDs, response formats, and what the output 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 100%, and the description adds value by providing examples for uniref_id and clarifying the response_format behavior (markdown default, json option, rejection of other values). This goes beyond the schema's basic definitions.

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

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

The description uses a specific verb ('Fetch') and resource ('UniRef cluster by ID'), with clear examples showing different identity levels. It distinguishes itself from sibling tools like uniprot_search_uniref by focusing on retrieval by ID.

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

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

The description implies when to use (to get a specific cluster), but does not provide explicit guidance on when not to use it or mention alternatives such as uniprot_search_uniref for query-based 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=true and openWorldHint=true, indicating safe, read-only operations. The description adds valuable context that only literature-described variants are included, which is a behavioral trait not captured by annotations. It also clarifies that the tool returns curated, not all, variants. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph of three sentences, each serving a distinct purpose: purpose, usage guidance, and limitation. No wasted words; front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a read-only lookup tool with solid schema documentation and annotations. It explains scope, distinguishes from a key sibling, and references another tool for complementary data. Output schema exists, so return values need not be described.

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 100%, so the parameters are already well-documented. The description does not add additional semantic meaning beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states 'List every literature-described natural variant UniProt has curated for an entry, including disease-associated mutations.' This defines the verb (list), resource (variants for a protein), and scope (literature-described natural variants). It is specific and distinguishable from sibling 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 description explicitly tells when to use this tool: 'Use this to see the full variant catalogue for a protein.' It also tells when not to use it and points to an alternative: 'to check one specific HGVS-shorthand change (e.g. 'R175H') use uniprot_lookup_variant instead.' Additionally, it references uniprot_resolve_clinvar for population-scale data.

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

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

The description adds the async polling behavior beyond the annotations (readOnlyHint and openWorldHint). It explains that the tool submits a job and polls to completion, which is important for the agent to understand the latency. No mention of error handling or rate limits, but the provided context is valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loading the purpose and immediately following with the key behavioral detail (async polling). Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with the rich input schema and presence of an output schema, covers the essential aspects: what the tool does, how it works (async/polling), and parameter details. It could mention that mappings may be many-to-many, but the output schema likely covers return format. Overall sufficient.

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 100%, so the input schema already documents each parameter clearly. The tool description does not add new meaning beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool maps identifiers between UniProt and external databases, using UniProt's ID mapping service. This is a specific verb-resource combination that distinguishes it from all sibling tools, none of which offer ID mapping.

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 mentions the async job submission and polling behavior, which informs the agent that the call may take a few seconds. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., uniprot_get_entry or uniprot_get_cross_refs) or when not to use it.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds valuable behavioral context: the limitation of UniProt annotations (literature-described only) and interpretation of null results, which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the core purpose, followed by examples and a critical caveat. Every sentence adds value without unnecessary text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to detail return values. It adequately covers purpose, parameter examples, and an important limitation (null meaning). The tool is fairly simple, and the description is complete for effective use.

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

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

Schema coverage is 100%, but the description adds examples for 'change' and 'accession', and clarifies the default and constraint for 'response_format'. This improves understanding beyond the schema alone.

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

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

The description clearly states it looks up an HGVS-shorthand amino-acid change in UniProt's natural-variant annotations, provides examples, and explains the return type. However, it does not explicitly differentiate from sibling tools like uniprot_get_variants, which might also retrieve variant information.

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 implicitly suggests use for variant lookup but does not explicitly state when to use this tool versus alternatives. It does provide a helpful caveat about null results, advising consultation of ClinVar/dbSNP, which partially guides usage.

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

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

Discloses output format (verification report with pass/drift/unreachable), explains the impact of wrong headers, and states that it makes prior responses auditable. This adds significant behavioral context beyond the annotations (readOnlyHint, openWorldHint) which only indicate safety and openness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-structured with a code block for technical detail, and each sentence adds value. It is front-loaded with the core purpose and then expands logically. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's verification role, the description covers input parameters, behavioral nuances, and output (verification report). An output schema exists, so return value details are optional. The description is self-contained and adequate for agent invocation.

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

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

With 0% schema description coverage, the description fully explains each parameter's purpose and defaults. It details the critical 'accept_header' parameter with examples and warns of consequences. The 'response_format' is mentioned but not elaborated, slightly reducing clarity.

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 specific verbs ('Re-fetch', 'verify') and identifies the resource (UniProt URL with release and response body). It clearly distinguishes itself from sibling tools that retrieve data by focusing on verification of provenance. No tautology.

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

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

Explicitly tells the user to pass values from a prior response's provenance footer and warns about matching the Accept header. It describes when optional fields are skipped. Lacks explicit 'when not to use' but the context makes it clear; alternative tools are not mentioned but are semantically different.

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

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

The description explains behaviors beyond annotations: relies on local file system cache (consistent with openWorldHint=false), is read-only (consistent with readOnlyHint=true), and returns cached body wrapped in Provenance. It even clarifies the annotation meaning. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short paragraphs, front-loading the primary action. It wastes no words, though the annotation explanation could be omitted as it's redundant with the input. Still, it's concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not detail returns. It covers cache conditions, offline use, and provenance. Minor omission: no error handling (e.g., cache miss), but for a simple replay tool this is acceptable.

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 for parameter meaning. It does not explain the 'url' parameter (what URL to use) nor the 'response_format' default. Only the return format is hinted. Without this, the agent cannot correctly construe the parameters.

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 explicitly states 'Read a previously-cached UniProt response without hitting the upstream,' clearly identifying the verb (read) and resource (cached response). It distinguishes from sibling tools that access upstream, e.g., uniprot_get_entry. This meets the highest standard.

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 lists specific use cases: reproducing old answers, working offline/air-gapped, and reducing upstream load. It also notes the cache is opt-in via an environment variable and reports cache-disabled when unset. While it lacks explicit direction on when not to use, these guidelines are sufficient for informed selection.

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

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

Beyond annotations (readOnlyHint, openWorldHint), the description adds behavioral context: it includes a direct EBI viewer link and notes that there is typically one canonical model per accession, hinting at variability. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no extraneous information. The first sentence front-loads the core action and cardinality; the second adds a high-value detail (EBI link). Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, annotations, and low parameter count, the description is largely complete. It mentions the key output feature (EBI link) and typical cardinality. It could briefly mention what happens when no model exists, but the openWorldHint somewhat covers that.

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 100%, so baseline applies. The description adds no additional parameter semantics beyond what the schema already provides for both 'accession' and 'response_format.'

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

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

The description clearly states it resolves the AlphaFoldDB cross-reference for a UniProt entry, specifying 'one canonical model per accession.' It distinguishes this from sibling tools like uniprot_get_alphafold_confidence, and includes mention of the EBI viewer link as a key feature.

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 when needing the AlphaFold cross-reference or a viewer link, but does not explicitly contrast with alternatives like uniprot_get_alphafold_confidence or state when not to use it. Guidance is adequate but not explicit.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds that the result may be empty for proteins without ChEMBL data and returns IDs with links. This adds mild context but does not disclose additional behavioral traits beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences that are front-loaded and directly state the tool's purpose and output. Every sentence is essential, with no superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown) and high schema coverage, the description provides a solid overview of the tool's function and output. It could be improved by mentioning error cases or the source of ChEMBL data, but it is sufficiently complete for a simple lookup tool.

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

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

Schema coverage is 100%, with both parameters (accession and response_format) well described. The description does not add meaningful details beyond the schema, such as the expected format of the returned data, so it meets the baseline.

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

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

The description clearly states it resolves ChEMBL drug-target cross-references for a UniProt entry, specifying the return of ChEMBL target IDs with EBI viewer links and the empty result case. However, it does not explicitly distinguish itself from sibling tools like uniprot_resolve_alphafold or uniprot_resolve_pdb, leaving differentiation to the tool name.

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 when ChEMBL drug-target cross-references are needed, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., other resolve tools) or when not to use it. No prerequisites or context 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 indicate readOnly and openWorld hints; description adds details about fetching entry, querying NCBI, and external dependency, with no contradictions.

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?

Well-structured in paragraphs with front-loaded purpose; every sentence contributes meaningful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present, description still explains return fields (significance, review status, etc.) and covers external API usage, making it complete for the tool's complexity.

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

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

Schema coverage is 100%, but description supplements with examples (e.g., 'R175H' for change), explains response_format options, and notes size cap at 50, adding value beyond schema.

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

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

Description clearly states it looks up ClinVar records for a gene encoded by a UniProt entry, distinguishing it from sibling tools like uniprot_lookup_variant by specifying it handles population-side variants.

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

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

Explicitly mentions it is critical for clinical workflows because UniProt annotations are limited, and advises combining with uniprot_lookup_variant for a complete picture. Also notes external API call and privacy declaration.

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

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

Annotations already indicate readOnlyHint and openWorldHint, so the description adds moderate context about cross-reference extraction but no additional behavioral details like error handling or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise and front-loaded with key action and resource, but lacks structural elements like bullet points or separate sections.

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?

Output schema exists, so return values need not be described; description adequately covers tool purpose and data source but omits error handling or parameter validation notes.

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

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

Schema coverage is 100%, and the description does not add new meaning to parameters beyond the schema's existing explanations; baseline score appropriate.

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

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

The description explicitly states 'List InterPro signatures' with clear focus on UniProt entries and distinguishes from sibling resolve_* tools by specifying InterPro specifically.

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 explicit when-to-use or alternatives are given, but the tool's name and description imply its purpose for InterPro data, providing minimal guidance compared to siblings.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral context: no extra HTTP call beyond entry fetch, pure-Python implementation. No contradictions.

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?

Three concise sentences: first states action and list, second provides rationale, third notes implementation detail. No waste, front-loaded.

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 presence of an output schema, the description is sufficiently complete. It explains the grouping, databases, rationale, and performance characteristic. Could mention expected output structure but not necessary due to output schema.

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 100%, so the schema already documents parameters well. The description does not add additional per-parameter details beyond the high-level grouping action, meeting the baseline for full schema coverage.

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

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

The description clearly states the tool's purpose: grouping orthology cross-references by source database, listing specific databases. It distinguishes from siblings by highlighting the no-extra-HTTP-call aspect and the comparative consensus reasoning.

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

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

The description provides context on when to use it (comparing orthologs across species, surfacing databases with different methods) and an efficiency hint (no extra HTTP call), but does not explicitly exclude alternatives or state when not to use.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description has a lower burden. It adds that the tool returns a 'structured list typed for downstream analysis' but does not disclose behaviors like error handling or data freshness. Adequate given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the primary purpose and key return fields. No unnecessary words or repetition. Each 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?

Given the presence of an output schema, annotations, and full schema documentation, the description is sufficiently complete. It covers the tool's function, key output fields, and a performance advantage. Could mention response_format handling but it's in the schema.

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 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter-level detail beyond what is in the schema, meeting the baseline.

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 'List' and identifies the resource 'PDB structure cross-referenced from a UniProt entry', clearly stating the output includes method, resolution, and chain coverage. It differentiates from siblings by highlighting speed and structured output.

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

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

The description implies when to use this tool over parsing raw cross-references ('Faster than parsing the raw cross-references blob'), but does not explicitly state when not to use or mention alternative tools. Provides clear context for its advantage.

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?

Discloses that size is capped at 500 server-side, explains response_format values, and clarifies that organism and reviewed_only are shortcuts. Annotations already indicate readOnlyHint and openWorldHint, but this adds valuable operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with purpose and usage, followed by examples and parameter explanations. Every sentence adds value with no fluff.

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 output schema exists, description needn't explain returns. It covers purpose, usage, parameter semantics, and behavioral traits, and distinguishes from sibling tools, making it fully complete.

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

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

With 100% schema coverage, baseline is 3. The description adds significant meaning: examples of query syntax, explanation of organism/reviewed_only as shortcuts, and description of response_format values, exceeding the schema's default descriptions.

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

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

The description clearly states it's the general-purpose entry point for finding UniProtKB proteins by any combination of gene, organism, keyword, or free text, and distinguishes from sibling uniprot_get_entry by specifying when to use each.

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

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

Explicitly says 'Use this first when you don't already have an accession; use uniprot_get_entry once you do.' Also explains that reviewed_only and organism are convenience shortcuts equivalent to adding clauses to query.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds return behavior (up to size matches, empty list if none) and a server-side cap of 500, which provides useful context beyond the annotations but does not discuss side effects or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with purpose, and every sentence adds value (purpose, workflow, sibling differentiation, examples, behavior). No wasteful text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (context signal), the description adequately covers tool behavior, parameter usage, and differentiation among many sibling tools. It provides sufficient context for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, baseline 3. The description significantly enhances meaning: explains query syntax with fields like author:, title:, year: ranges, gives examples, clarifies size cap, and describes response_format options including that invalid values are rejected.

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

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

The description clearly states the tool searches the UniProt citations index by title, author, or year, and explicitly distinguishes from sibling tools like uniprot_get_citation and uniprot_get_publications.

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 explains the workflow: find a citation's ID with this tool, then call uniprot_get_citation for full record. It also provides an alternative for protein-specific publications (uniprot_get_publications) and includes query examples.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral details: returns up to size matches, server-side cap at 500, response format options, and that query is plain text not field query. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but well-organized: purpose, usage instruction, return behavior, examples. It is concise but could benefit from slightly more structure (e.g., separation of return info). Still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and existence of output schema, the description covers all necessary aspects: purpose, usage, parameters, behavior, and output options. No gaps.

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 covers 100% of parameters with descriptions. The description adds meaning beyond schema by giving examples for 'query', clarifying the size cap, and explaining response_format options. It enriches parameter understanding.

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

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

The description clearly states it searches UniProt's controlled keyword vocabulary, with specific examples and differentiation from the sibling tool uniprot_get_keyword. The verb 'search' and resource 'keyword vocabulary' are specific, and it distinguishes from 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?

Explicitly tells when to use: 'Use this to discover a keyword ID from a concept; once you have the KW-#### ID, call uniprot_get_keyword for its full record.' It also explains return behavior (up to size matches, empty list) and mentions cap at 500.

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 provide readOnlyHint and openWorldHint. The description adds that it performs a search and returns results in markdown or json, with invalid formats rejected. This aligns with annotations and adds some context but doesn't reveal additional traits beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but well-structured: purpose first, then usage flow, return behavior, and examples. No wasted words; 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 3 parameters, output schema present, and annotations, the description covers the tool's function, usage flow, and expected output. It links to a related tool. Could mention pagination or error behavior more explicitly, but 'empty list' and 'rejected' statements provide adequate completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description enriches all parameters: query with examples (organism_id:9606, etc.), size with capping behavior, response_format with rejection details. This provides practical usage guidance beyond schema descriptions.

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

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

The description clearly states the verb 'Search' and the resource 'UniProt proteomes', and distinguishes from sibling `uniprot_get_proteome` by saying this tool is for finding the UP ID and the other for the full record. Examples reinforce the purpose.

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

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

The description explicitly advises using this tool to find a proteome ID, then switching to `uniprot_get_proteome` for details. It also explains that it returns up to `size` matches or an empty list. However, it does not explicitly state when not to use it or list alternatives beyond the one sibling.

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 declare readOnlyHint and openWorldHint. Description adds context: it searches by name/definition, returns matches, and the query is free-text (not UniProtKB field query). No contradictions; fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus an example line. Front-loaded with purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the clear annotations, complete schema, and existence of output schema (not shown but noted), the description provides all necessary context. References sibling for next step and explains response format options.

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 covers all 3 parameters with descriptions. The description adds little beyond schema; for query it repeats examples, for size it says 'up to size matches' which is implied. With 100% coverage, baseline 3 is appropriate.

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

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

The description clearly states it searches UniProt's controlled subcellular-location vocabulary by name or definition, with specific examples and differentiation from uniprot_get_subcellular_location.

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

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

Explicitly tells when to use this tool ('discover a location ID from a concept') and when to use the sibling ('call uniprot_get_subcellular_location for its full record'). Also explains result behavior (up to size matches, empty list if none).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's assertion that this is a search operation is consistent. It adds that results are capped at 500 server-side and describes the response format options. This adds value beyond annotations but does not disclose any unexpected behaviors (e.g., rate limits, data staleness).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences. The first sentence front-loads the purpose and entry point role. The second provides examples and a workflow pointer. Every sentence adds value; no fluff or repetition. This is an exemplary concise description.

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 presence of an output schema, the description does not need to explain return values. It covers query syntax, size limit, and response format. The workflow hint (search then get) ties it to sibling tools. It could mention pagination behavior beyond the size cap, but overall it is sufficiently complete for an agent to use correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds concrete examples for the query parameter (e.g., 'taxonomy_id:9606') and explains the query language link. For size, it notes the server-side cap of 500. For response_format, it clarifies the difference between markdown and json. These details improve usability beyond the schema descriptions alone.

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

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

The description clearly states it searches UniParc by taxonomy, source database, or other query fields, and distinguishes itself from sibling tool uniprot_get_uniparc by noting that it is the entry point when you don't have a UPI. The verb 'search' combined with the specific resource 'UniParc' and context 'non-redundant sequence archive' makes purpose unambiguous.

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

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

The description explicitly states when to use this tool ('entry point when you don't already have a UPI') and what to do next ('once you have a UPI... use uniprot_get_uniparc'). Examples are provided. However, it does not contrast with other search tools like uniprot_search, which could cause confusion if the user is targeting a different database.

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

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

The description explains response format options (markdown with provenance footer vs. JSON) and the server-side cap on size (500). Combined with annotations (readOnlyHint, openWorldHint), the behavior is well disclosed. Minor missing details like pagination behavior beyond the cap are not critical.

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?

Three sentences efficiently cover purpose, usage distinction, example, and tier guidance. No filler words; every sentence serves a purpose. Front-loaded with the core distinction.

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 presence of an output schema and 100% parameter coverage, the description adequately covers usage context and parameter semantics. It could mention result ordering or error handling, but the description is sufficient for typical scenarios.

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 covers all parameters (100% coverage), but the description adds value: explains identity_tier thresholds with examples (50, 90, 100) and their implications, clarifies the response_format options, and gives a query example. This goes beyond the schema's descriptions.

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

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

The description clearly states the tool searches UniRef clusters by content, contrasting with uniprot_get_uniref for known IDs. An example ('kinase') and tier values solidify the purpose, distinguishing it from sibling search or 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?

Explicitly advises using uniprot_get_uniref for known cluster IDs and provides guidance on identity tier selection ('looser tier (50) to find broad homology groups, tighter (100) for near-identical sets'). This covers when and why to use different options.

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?

Discloses network call optimization ('two upstream network calls, not nine') and output format options, adding value beyond readOnlyHint and openWorldHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet points, front-loaded purpose. Slightly lengthy but every sentence earns its place; compresses 9 views into clear enumeration.

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?

Fully explains purpose, usage context, behavioral details, and parameter constraints. Output schema handles return specifics; description complete for entry-level summary 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?

Both parameters well-documented in schema (100% coverage). Description adds minor detail ('Any other value is rejected' for response_format) but largely redundant.

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

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

Description clearly states 'One-call comprehensive characterisation of a UniProt entry' and lists nine specific views, distinguishing it from sibling tools that provide narrower or deeper detail.

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

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

Explicitly directs to use for entry-level summary to decide on deeper tools, and provides alternative tools for specific needs (e.g., pLDDT, full disease detail).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to cover safety. It adds important behavioral details: returns multiple matches for ambiguous names, requires inspecting rank and scientific name. It does not mention rate limits or quotas, but the annotations and description together are sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph of four sentences, each serving a purpose: primary function, output details, ambiguity handling, and usage guidance. No wasted words, front-loaded with the core action.

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 presence of an output schema, the description does not need to detail return values, but it already lists the returned fields. It covers ambiguity, response formats, and usage context, making it complete for an agent to decide to invoke this 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 100%, but the description adds significant value beyond the schema: explains that query matches against scientific and common names, details the response_format options ('markdown' with provenance footer, 'json' for machine-parseable), and notes that size is capped at 500 server-side.

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

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

The description clearly states it resolves an organism name to NCBI taxonomy IDs, which is a specific verb+resource. It distinguishes itself from sibling search tools by focusing on taxonomy resolution and explains the context of use (other UniProt tools expect numeric IDs).

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

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

The description explicitly says 'Use this before filtering any other search by organism if you only know the name, not the numeric ID.' It also provides guidance on handling ambiguous results and mentions the response format options, giving clear when-to-use and when-not-to-use context.

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