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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that data is aggregated from multiple PDBe-KB partner resources and enumerates return contents, which is useful context but does not add auth, rate-limit, or pagination behavior.

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

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

Two sentences, front-loaded with the core purpose before the enumeration of returned fields. The parenthetical examples and return list are dense but each element conveys content; nothing is filler.

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

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

With no output schema, the description carries the return-value burden and does so by listing annotation type, per-residue scores, confidence metrics, group labels, resource URL, and Best Chain ID. For a read-only tool this is nearly complete, missing only usage routing.

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

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

Schema description coverage is 100%, so both parameters (pdb_id, entity_id) are already documented with format and pattern constraints. The description reiterates the PDB Entity ID but adds no syntax or constraint meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Returns) and resource (residue-level functional and biophysical annotations for a PDB Entity ID), and names the aggregation sources. The residue-level scope distinguishes it from sequence-level siblings, but it does not explicitly name an alternative to route the agent.

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 explains what the tool returns but gives no when-to-use or when-not-to-use guidance, and never names a sibling alternative despite many adjacent per-entity tools (sec_struct, bind_sites, doms). Usage is only implied by the input being a PDB Entity ID.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description contributes meaningful domain behavior — that chains must be non-overlapping and are chosen to maximize covered observed residues — which is the kind of algorithmic context annotations cannot carry. However, it says nothing about result ordering, pagination, or what happens when no chains cover the accession, and the idempotentHint=false on a pure lookup is left unexplained.

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

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

One sentence with zero filler, and the discriminating selection criterion (non-overlapping chains maximizing observed-residue coverage) is front-loaded rather than buried. Nothing redundant or padded.

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 one-parameter read-only lookup with no output schema, the description conveys the essential selection semantics an agent needs to interpret the result set. The remaining gap is edge-case behavior (empty results, ordering) and disambiguation from the near-duplicate sibling, which slightly holds it below a 5.

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% for the single 'uniprot_accession' parameter, so the schema already documents it. The description only restates 'for a given UniProt accession' without adding format details (e.g. primary vs secondary accession handling). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Retrieve a list of non-overlapping PDB chains') plus the selection criterion (covering the largest number of observed residues) for a given UniProt accession. It is far more specific than a tautology, but it offers no differentiation from the near-identical sibling 'best_soubsu_acc_11b902cf', so an agent cannot tell the two apart from the text alone.

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

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

There is no guidance about when to use this tool versus the other chain/structure retrieval siblings (e.g. chains_ent_chains_id_entity_id, best_soubsu_acc), no prerequisites, and no exclusions. The description only says what the tool returns, leaving the agent to infer its place among roughly thirty siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds value by disclosing the ranking basis (data quality, model quality, resolution) and enumerating the returned fields. It says nothing about result limits, pagination, or handling of accessions with no mapped structures, which is a real gap for a lookup tool with no output schema.

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

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

Two sentences, front-loaded with purpose and ranking logic before the field inventory. The second sentence is a long enumeration, but given the absence of an output schema that detail earns its place rather than being filler.

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

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

With no output schema, the description usefully specifies what each returned structure entry contains, including coverage and alignment segments. It stops short of covering edge cases (no results, very large result sets, ordering ties), which keeps it from being 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?

Schema description coverage is 100% and there is a single required parameter, so the baseline is 3. The description only restates 'the given UniProt accession' without adding format, validation, or multi-accession semantics beyond what the schema already conveys.

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

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

The description gives a specific verb and resource ('Provides a ranked list of PDB structures mapped to the given UniProt accession') and even states the ranking criterion, so an agent knows exactly what it returns. It does not, however, differentiate itself from closely named siblings such as best_nosoubnosu_acc_bf133eee, which likely returns a complementary set of structures.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The mention that ranking is by an 'internal quality score' hints at why one would pick this over a raw structure lookup, but the agent must infer that, and nothing steers it between this tool and the many sibling mapping/annotation tools.

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

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

Annotations already declare the safe read profile (readOnlyHint=true, destructiveHint=false), so the description is not carrying the safety burden. It does add real value by detailing the payload (CCD ID, ligand name, interacting residues grouped by Bound Molecule ID, ARPEGGIO basis), which partially compensates for the absent output schema, but it says nothing about edge cases such as entities with no ligands or invalid entity IDs.

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

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

Two sentences with the purpose front-loaded and output detail second; nothing is wasted. The only minor issue is that the second sentence is dense with field names and reads as a payload inventory rather than crisp prose.

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

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

For a two-parameter read-only endpoint with full schema coverage and no output schema, the description covers both the purpose and the shape of the return payload, which is the main missing artifact. It stops short of describing pagination, error behavior, or empty-result handling, keeping it just under 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?

Schema description coverage is 100%, so both pdb_id and entity_id are fully documented in the schema (including the numeric pattern for entity_id). The description references 'a specified PDB entity' but adds no format, range, or lookup guidance beyond the schema, so the baseline of 3 applies.

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

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

The description states a concrete verb and resource: 'Returns ligand-binding site annotations for a specified PDB entity,' which is specific enough to distinguish from generic annotation tools. However, it never names or contrasts with close siblings such as iface_res_ent_interfaces_id_entity_id or annot_ent_annot_id_entity_id, so an agent cannot route on the description alone.

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

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

There is no when-to-use guidance, no stated prerequisites (e.g., needing a valid entity that has bound ligands), and no mention of alternatives like bound_molecules or comp_intx. The agent must infer usage entirely from the purpose sentence.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond that by enumerating exactly what is returned — full composition with CCD IDs, internal connectivity format, and the specific interaction types computed for the preferred assembly — which is meaningful 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?

Content is front-loaded into a single sentence and every clause conveys return-scope information. It is dense and crowded with parenthetical examples, but not padded with filler.

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

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

With no output schema, the description carries the full burden of describing returns, and it does so thoroughly — composition, connectivity encoding, and interaction categories. An agent knows what it will get back and the two required inputs.

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% for both parameters, so the schema already documents pdb_id and bm_id. The description adds a concrete bm_id example ('bm1') but nothing about pdb_id format or constraints, making this a baseline case.

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

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

The description states a specific verb (returns) and resource (composition and high-level interactions for a specific Bound Molecule ID of a PDB entry), with a concrete example id ('bm1'). It is clear what the tool produces, though it does not explicitly differentiate itself from the sibling bound_molecules tool that supplies the bm_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 gives no when-to-use or when-not-to-use guidance and names no alternative. The only routing hint ('can be obtained from the output of bound_molecules call') lives in the schema field description, not the tool description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered, but the description goes further by describing the payload itself: Bound Molecule IDs (bm1, bm2), composition via unique CCD IDs, and a worked example of the connectivity notation. With no output schema present, this return-shape detail is genuinely additive.

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

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

A single front-loaded sentence leads with the core purpose, then appends clarifying examples for the connectivity notation. It is dense but every clause (carbohydrate polymers, CCD composition, F1/F6 example) earns its place by decoding an otherwise opaque return field.

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 one-parameter read-only lookup with no output schema, the description supplies enough about the returned content (IDs, composition, connectivity) that an agent can interpret results. It is nearly complete, lacking only sibling disambiguation against bound_mibmiib_id.

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 single pdb_id parameter is fully documented in the schema as a 4-character PDB id code. The description adds no format, validation, or alternate-input meaning beyond 'for a given PDB entry ID', so the baseline 3 applies.

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

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

States a specific verb and resource: returns all bound molecules for a given PDB entry ID, with an explicit scope note ('including carbohydrate polymers'). An agent knows exactly what data it gets. It stops short of naming or contrasting with the near-duplicate sibling bound_mibmiib_id, so it does not fully differentiate at selection time.

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

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

There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives such as the closely named bound_mibmiib_id sibling. The only implied context is that you must supply a PDB entry ID, which is already enforced by the required parameter.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine value by disclosing the response caveat that chainId in additionalData is struct_asym_id rather than auth_asym_id, a subtlety an agent could not otherwise anticipate.

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?

It is a single sentence, so there is no wasted padding, but it is dense and the parenthetical struct_asym_id caveat is tacked onto the end rather than front-loaded. The key routing information is present but buried.

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

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

With no output schema, the description carries the burden of explaining returns and does so reasonably well by enumerating chains, residue ranges, validation data, and metadata. Missing only pagination/response-size behavior, which is a minor gap for a per-entity lookup.

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 both parameters (pdb_id, entity_id) are documented in the schema, so the baseline of 3 applies. The description reinforces that entity_id is an entity/molecule identifier but adds no format or constraint detail 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 states a specific verb ('Returns') and resource ('detailed chain-level annotations for a specified PDB Entity ID') and enumerates the returned content (polymer chains, residue ranges, per-residue validation, Best Chain ID). It is clear on its own but never distinguishes itself from the many sibling entity-level tools (e.g. annot_ent, molecules_ent, seq_cescie).

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

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

There is no explicit when-to-use or when-not-to-use guidance and no alternatives are named, despite a large set of similar per-entity sibling tools. Usage must be inferred entirely from the return-content description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond the annotations: the match is deliberately broad, covering the component both standalone and as part of a larger entity, which answers the key ambiguity an agent would have about exact vs. containment matching. It stops short of describing result size, ordering, or pagination.

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 tight sentences with the core purpose front-loaded and the matching-scope qualifier second; no filler or redundant restatement of the title. Slightly verbose phrasing ('as defined in the PDB Chemical Component Dictionary') but it earns its place by defining the identifier source.

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 one required parameter, no output schema, and annotations present, the description covers the essentials: what the tool returns and how the match is scoped. Because there is no output schema, it would ideally say what a returned 'PDB entry' looks like (IDs only vs. records) or whether the list is capped, which is a real gap.

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

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

Schema description coverage is 100% for the single parameter, so the baseline is 3. The description does add a little meaning by tying the hetcode to the PDB Chemical Component Dictionary, but the schema already states 'Hetcode for the compound' and the description gives no format or case examples.

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

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

Specific verb+resource: it returns PDB entries containing a given chemical component, and it clarifies the matching scope (standalone component or part of a larger entity). That scope statement meaningfully disambiguates from a plain 'entry lookup', but the description never names a sibling (e.g., ligand_sum_comp_sum_hetcode or similar_ligands_comp_similarity_hetcode) to help an agent choose between the component-related 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 when-to-use guidance, no prerequisites, and no alternatives are mentioned despite several component/ligand siblings existing (similar_ligands, comp_intx, ligand_sum). The agent must infer from the return semantics alone that this is the 'which entries contain this hetcode' 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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: the counts are aggregated across all PDB structures and grouped by interaction type, i.e. the result is a summary rather than raw per-structure hits. It does not address result size, pagination, or why idempotentHint is false for what reads as a deterministic aggregation.

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, zero filler, and the most decision-relevant fact (aggregated interaction counts for a chemical component) is front-loaded in the first clause. The second sentence productively fills in the return shape rather than padding.

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

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

With no output schema, the description carries the burden of describing the return and does so reasonably: frequency of ligand-atom-to-residue interactions, grouped by interaction type. For a single-parameter read-only aggregation tool that is nearly complete, though it omits any sense of result granularity or size.

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% for the single 'hetcode' parameter, so the baseline is 3. The description only weakly re-frames the parameter by saying the results are derived from structures 'containing the given chemical component'; it adds no lookup semantics, format, or case-sensitivity 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?

States a specific verb and resource ('Returns aggregated interaction counts for protein-ligand interactions') and defines the data scope ('derived from all PDB structures containing the given chemical component'). It is clear what the tool produces, but it does not differentiate itself from siblings such as comp_intx_proteins_comp_unip_hetcode or ligand_sum, which the agent must disambiguate on its own.

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

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

There is no when-to-use guidance, no statement of exclusions, and no named alternative. The closest thing to context is the scope note that results are aggregated over all PDB structures, which tells the agent what data is covered but not when to prefer this tool over the several sibling interaction/summary tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description usefully adds that results are filtered to UniProt-mapped chains and include UniProt metadata, but says nothing about result volume, pagination, or behavior when a hetcode has no mapped partners.

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

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

A single front-loaded sentence with no filler; the key scoping qualifier (interacts + mapped to UniProt) appears before the metadata clause. Slightly dense, but every clause 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 one-parameter read-only lookup with no output schema, the description adequately covers what is returned (interacting protein chains plus UniProt metadata). Remaining gaps (pagination, empty-result behavior) are minor given the tool's simplicity and its readOnly annotation.

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% for the single 'hetcode' parameter, so the schema carries the parameter burden. The description restates the input as 'the given chemical component' but adds no format, casing, or lookup-syntax detail 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 states a specific verb ('Returns') and a precisely scoped resource: protein chains in PDB entries that interact with a given chemical component AND are mapped to UniProt. That mapping filter distinguishes it from the broader sibling comp_intx_comp_intx_hetcode and ligand_sum_comp_sum, though it names no sibling explicitly.

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

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

Usage is implied: supply a hetcode to get its interacting UniProt-mapped protein chains. There is no explicit when-to-use statement, no exclusions, and no pointer to the sibling comp_intx tool for non-UniProt-mapped interactions, so the agent must infer the boundary.

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, destructiveHint=false and idempotentHint=false, so the safety profile is covered. The description adds only the parenthetical '(if any)', hinting that subcomplexes may be absent, but says nothing about return format, identifier resolution behavior, or what happens on an unknown id.

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

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

A single compact sentence with the resource front-loaded and no filler. It is efficient, though a longer description might have earned its space by adding routing or return-format detail.

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

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

For a simple two-required-parameter lookup with no output schema, the description names both return components (participants and subcomplexes) and no nested objects exist. It is minimally adequate, but the absence of an output schema means a bit more detail on the response shape would have helped.

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 allowed id_type values are enumerated in the schema, so the description need not restate them. It adds no syntax, format, or cross-parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('Get') and resource ('list of participants and subcomplexes') scoped to 'the given identifier'. The purpose is clear and unambiguous, but there is no differentiation from the many similarly-named sibling tools (e.g. bound_molecules, molecules_ent), which all operate on identifiers.

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 when-to-use guidance, prerequisites, or alternatives are given. The description does not indicate how this differs from siblings like molecules_ent or bound_molecules that also take an id, leaving an agent to guess which retrieval tool to pick.

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, destructiveHint=false and idempotentHint=false, so the safety profile is covered. The description adds no behavioural detail such as pagination, response size, or coverage caveats; its only real contribution is enumerating the returned domain resources, which is return-value content rather than behaviour.

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

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

A single front-loaded sentence with the verb and resource first, followed by source list and metadata. It is a little list-heavy at the tail (Best Chain ID), but nothing is redundant enough to waste the agent's reading budget.

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

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

With no output schema, the description carries the burden of describing returns and does so concretely (domain boundaries, identifiers, names, source databases, Best Chain ID metadata). Both parameters are documented in the schema and the operation is read-only, so little is missing beyond guidance on failure/empty 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 description coverage is 100% and the schema already specifies the 4-character PDB id and the numeric entity id pattern. The description only references 'a specified PDB Entity ID' and adds no format, range, or cross-parameter constraints beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns sequence and structural domain annotations') and enumerates the exact source databases (CATH, SCOP 1.75, Pfam, InterPro), which distinguishes it from generic neighbours like annot_ent_annot. It stops short of explicitly naming which sibling to use instead, so it earns a 4 rather than a 5.

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

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

There is no statement of when to use this tool, when not to, or which sibling covers the adjacent case (e.g. annot_ent_annot for general annotations, sec_struct for secondary structure). The 'for a specified PDB Entity ID' clause only restates the required input, not usage context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered without prose. The description adds real value by clarifying that chain_id means label_asym_id rather than a generic chain id, but it says nothing about return format (one-letter vs three-letter codes) or handling of modified residues.

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

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

A single front-loaded sentence with zero filler. The core action and the two scoping identifiers appear immediately, and nothing is repeated from the schema.

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 read-only, two-parameter retrieval with fully documented parameters, the description covers what is returned and how it is scoped. The absence of an output schema is largely compensated by 'returns the amino-acid sequence', though format details remain unspecified.

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, but the parenthetical '(label_asym_id)' genuinely disambiguates chain_id, which the schema only describes circularly as 'PDB chain id'. That distinction (label vs auth asymmetry) is a real footgun in PDB APIs, so it earns a step 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?

States a specific verb (returns) and resource (amino-acid sequence) scoped to two identifiers (PDB Entry + Chain ID), so the agent knows exactly what it gets. It does not differentiate itself from sequence-oriented siblings such as seq_cuuscu_acc or seq_cescie_id, so it falls short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no alternatives named among the many sibling tools. The agent must infer from the name alone when this retrieval is preferable to the other sequence endpoints.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real value beyond them by naming the data source (PISA) and the shape of the payload: interaction types such as salt bridges and hydrogen bonds, interatomic distances, and atoms/residues from both interacting chains. It does not mention result size, pagination, or ordering.

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

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

Three sentences, front-loaded with the core action and followed by return content and filtering options; nothing is padded. Minor repetition between the opening clause and the filter sentence keeps it just short of ideal.

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

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

With no output schema, the description does carry the burden of describing return values, and it does so at a useful level (interaction types, distances, participating residues). It stops short of covering result volume or ordering, but for a three-parameter read-only tool it is nearly 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%: pdb_id (4-character code), assembly_id (numerical), and interface_id (one-based index) are all documented in the schema itself. The description only restates that the latter two act as filters and adds no format or semantics beyond the schema, matching the 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?

The description states a specific verb and resource ('Returns all interface residue contacts calculated by PISA') scoped to a PDB entry ID. However, it does not differentiate itself from the near-duplicate sibling iface_res_ent_interfaces_id_entity_id_49a0e419, so an agent cannot tell the two apart from text alone.

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

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

It notes that results can 'optionally be filtered by assembly_id and interface_id', which implies a use case, but there is no guidance on when to choose this tool over the similar interface-residue sibling, nor any prerequisites or exclusions. Usage must be inferred entirely.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context by describing the payload: per-partner UniProt accession, name, interface residue ranges, and Best Chain ID metadata. This is useful because there is no output schema. It does not cover error behavior or empty-result cases, keeping it below 5.

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

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

Two sentences, front-loaded with the core output and then the payload details; nothing is repetitive. The second sentence is somewhat dense but each clause (partner accession, name, residue ranges, Best Chain ID) conveys distinct content. Slightly tighter phrasing would earn a 5.

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

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

For a two-parameter read-only endpoint with no output schema, the description supplies the missing return-value structure and safety context via annotations. Parameters are fully documented by the schema. The main remaining gap is the complete absence of usage/routing guidance relative to the many sibling tools.

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

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

Schema description coverage is 100% for both parameters, so the schema already carries the semantics (4-character PDB id, numeric entity id with pattern). The description restates the entity ID concept ('specified PDB Entity ID') and implies the PDB id but adds no format, range, or lookup guidance beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource: returns protein–protein interface residues for a PDB Entity ID, specifically PISA-detected contacts with partner proteins. An agent can identify what the tool produces. However, it never distinguishes itself from the very similar sibling ent_iface_res_ent_iface_res_id_e3f93cbf (or bind_sites_ent_bind_sites), so the boundaries between overlapping interface/binding-site tools remain unclear.

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 contains no when-to-use, when-not-to-use, or alternative-tool guidance at all. It does not mention prerequisites beyond the required parameters (e.g. that PISA annotations must exist for the entity, or that a valid entity must already be resolved). The agent is left to infer selection purely from the name and description.

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, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond the annotations: it details the per-category return content (residue/instance counts, outlier counts, percent outliers, RMSZ) and notes that empty categories return null percentages, which matters because no output schema exists.

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

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

The purpose is front-loaded in the first sentence, followed by an enumerated breakdown of return fields. Every sentence carries content, though the inline bullet list is a bit dense and could be trimmed without loss.

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?

Because there is no output schema, the description must explain the return value, and it does so in some depth (categories, counts, outliers, percentages, RMSZ, null handling). The main gap is the absence of any routing guidance relative to the closely related outlier 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?

There is a single required parameter, pdb_id, and schema description coverage is 100%, so the schema already documents it fully. The description adds no parameter-level detail, but the baseline of 3 applies when structured data does the heavy lifting.

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

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

States a specific verb and resource: it 'provides a validation summary' of geometric and electron-density metrics, and enumerates the categories covered (bonds, angles, RNA suite, Ramachandran, sidechains, RSRZ). That is far clearer than the opaque tool name. It does not, however, distinguish itself from the related outliers tool (outliers_val_outliers_all_id...), leaving the sibling boundary unstated.

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 never says when to use this tool versus alternatives such as outliers_val_outliers_all_id..., nor does it state prerequisites or the context in which a full validation summary is preferred over a raw outlier list. Usage is only loosely implied by the content it returns.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating what the summary contains (structure IDs, descriptors, synonyms, PDB metadata, functional annotations, cross-refs). It does not explain the unusual idempotentHint=false for what is clearly a pure read, nor any return format or rate behavior.

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

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

A single front-loaded sentence with the core action first and the content enumeration second. The long list of returned categories is slightly padded but every element is informative, with no wasted framing.

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

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

With no output schema, the description usefully enumerates the returned content categories, which is exactly what an agent needs to judge relevance. Given a single well-documented parameter and read-only annotations, this is nearly complete, missing only explicit routing to/from sibling tools.

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

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

Only one parameter ('hetcode') with 100% schema description coverage, so the schema carries the parameter documentation. The description reinforces that hetcode identifies the compound but adds no format, case, or lookup semantics beyond that. 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?

States a specific verb ('returns a summary') and resource ('chemical component identified by the given hetcode'), then enumerates the content categories. This differentiates it from interaction siblings like comp_intx and similarity tools like similar_ligands, though it never names a sibling explicitly.

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

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

No when-to-use guidance, no preconditions, and no alternative tools named. The agent must infer from the purpose alone that this is the broad summary entry point versus the more specialized sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes further and itemizes the response content — PDB structures, residue-level annotations with UniProt vs PDB numbering, provider, citations, entity type, textual evidence, annotator, and confidence scores — giving meaningful behavioral context for an unannotated output. It omits rate limits and auth requirements, so not a 5.

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

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

The core action is front-loaded in the first sentence, and the remaining sentences describe the return payload. It is somewhat dense and a touch verbose for a one-parameter read tool, but every sentence carries information the agent cannot get from the schema or annotations.

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

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

For a single-parameter read-only tool with no output schema, the description compensates well by detailing what the response contains and how positions are numbered. The only gap is the absence of usage routing among the many similar sibling tools, which limits how confidently an agent can select it.

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

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

There is a single required parameter and schema description coverage is 100%, so the schema already documents uniprot_accession. The description only restates 'for a given UniProt accession' without adding any format, identifier convention, or example, so the baseline of 3 applies.

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

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

The description states a specific verb ('Retrieve') and resource ('text mined annotations for a given UniProt accession'), which is concrete and unambiguous. It does not, however, explicitly differentiate itself from the many annotation-related siblings such as unip_gen_annot_unip_annot_unip_acc, leaving the agent to infer the distinction from the 'text mined / machine-predicted' framing.

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

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

There is no when-to-use guidance, no conditions, and no mention of alternative tools. The closing phrase about 'comprehensive exploration of machine-predicted functional and structural insights' gestures at a use case but stops short of telling the agent when this tool is the right choice over its annotation-heavy siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully discloses what is returned (mapped residue segments plus per-resource annotations), but it does not explain the idempotentHint=false flag or whether repeated queries vary, leaving a gap that structured fields raise but do not resolve.

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 tightly packed sentences that lead with the core capability and then the query directions and return content. Dense but front-loaded with no filler, though the resource list is long enough to slow scanning.

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

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

With no output schema, the description takes on return-value disclosure and does so by stating it returns mapped residue segments and per-resource annotations. Combined with readOnly annotations and a fully documented single parameter, an agent has everything needed to invoke it 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% and the single accession parameter is fully documented in the schema, including all accepted identifier types. The description's mention of auth_asym_id/struct_asym_id adds chain-identifier context but no syntax beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a concrete verb and resource: it provides unified SIFTS residue-level mappings between PDB protein chains and named sequence/domain resources (UniProt, Pfam, InterPro, CATH, SCOP, GO, Ensembl, HMMER). This is specific enough to distinguish it from sibling tools like seq_cescie or unip_map_ent, though it does not explicitly name which sibling to use instead for overlapping mapping tasks.

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 says it "Supports both PDB-to-identifier and identifier-to-PDB queries," which implies bidirectional usage, but it gives no explicit when-to-use or when-not-to-use guidance relative to the many sibling mapping/annotation tools. Usage context is implied rather than stated.

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, destructiveHint=false and idempotentHint=false, covering the safety profile. The description adds value by enumerating the returned content (UniProt names, DrugBank synonyms, sequences, chains, copy numbers, source organism), which matters because no output schema exists, but it says nothing about behavior when entity_id is omitted or how errors are handled.

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

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

One front-loaded sentence with the core purpose first, which is good. But the field enumeration is a long, comma-heavy list with mild redundancy ('summarised detailed information') and it duplicates the title verbatim, making it dense without much structure.

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

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

With no output schema, enumerating return fields is the right move and the description does that. Gaps remain: it does not explain what happens if the optional entity_id is omitted, and it does not relate the tool to the numerous sibling entity tools, so the agent lacks routing context.

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

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

Schema description coverage is 100% and both parameters (pdb_id, entity_id) are documented in the schema, so the baseline is 3. The description clarifies the mmcif meaning of 'entity' but adds no format or optionality detail 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?

States a specific verb and resource: returns summarised information about each molecule/entity in a given PDB entry, and enumerates the returned fields. However, it never distinguishes itself from entity-level siblings like bound_molecules, ligand_sum, or doms_ent that also operate on a PDB id / entity 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?

There is no guidance on when to choose this tool over the many entity-level siblings, nor any mention of prerequisites or exclusions. The agent must infer usage from the field list alone.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false. The description adds context about output structure (unit-id notation, types_of_outliers section) but does not disclose behavior beyond what annotations cover, such as result size or pagination. For a read-only listing tool, the annotations already carry the safety profile; the description adds modest value.

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 primary purpose, followed by output format detail. Some redundancy in the category enumeration, but overall efficient 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?

Given no output schema exists, the description helpfully explains the return structure (unit-id notation, types_of_outliers section). This compensates for the absent output schema. It is nearly complete for a read-only listing tool with a single documented parameter.

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 there is a single parameter (pdb_id) fully documented in the schema. The description adds no parameter-specific information, which is the baseline expectation when the schema does the heavy lifting.

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

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

States a specific verb and resource: lists all geometric and model-data outliers from MolProbity, grouped by category. The enumerated categories (clashes, sidechains, RSRZ, etc.) make the scope concrete. Sibling tools are entirely different structural queries, but the description does not explicitly distinguish from them — though none of the siblings appear to overlap this function, so minimal differentiation is needed.

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 when-not-to-use guidance. Usage is implied by the name and single required parameter (a PDB id). No alternatives are named, though none of the sibling tools serve the same outlier-listing purpose, so the risk of misuse is low.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully discloses the return content (PDB entries, RNA chains, matched regions), but adds no auth, rate-limit, or pagination context. With annotations carrying the safety burden, this is adequate but not rich.

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

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

A single front-loaded sentence with no filler; every clause describes the returned resource. Efficient, though it could spend a few words on input flexibility or usage.

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?

No output schema exists, and the description compensates by naming what is returned (PDB entries, RNA chains, matched regions). Combined with annotations covering the safety profile, an agent has enough to invoke it, though the Rfam-vs-PDB-ID input ambiguity is left unresolved.

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 the single parameter. The description narrows the input to 'Rfam accession' while the schema explicitly allows 'Rfam accession or PDB ID', which is slightly less informative than the schema rather than adding meaning. Baseline 3 for full 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?

States a specific verb (returns) and resource (PDB entries and RNA chains mapped to a Rfam accession, including matched regions), which is far more informative than the name alone. It is clear what the tool produces, though it does not differentiate itself from the many sibling mapping/accession tools (maps_maps_acc, best_soubsu_acc, etc.).

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 when-to-use, when-not-to-use, or alternative routing is provided. Given ~35 sibling tools that also key off accessions/IDs, an agent gets no help deciding when rfam_nucleic_maps is the right call versus maps_maps_acc or the unip_* tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully discloses what is returned (per-residue predictions plus scores, labels, and source metadata), which matters because there is no output schema, but it does not explain the odd idempotentHint=false on a read operation or any rate/coverage 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?

A single front-loaded sentence that begins with the action and resource before listing contents. It is slightly dense with parenthetical examples but every clause carries information; no padding.

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

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

With no output schema, the description's enumeration of returned fields (helices, strands, per-residue predictions, scores, labels, source metadata) is the primary source of return-value information and is reasonably complete. The gaps are the missing usage routing and the unexplained non-idempotent read hint.

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%: pdb_id and entity_id are both documented in the schema (including the numeric pattern for entity_id). The description only restates 'specified PDB Entity ID' and adds no format or constraint detail, so it sits at the baseline where the schema does the work.

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

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

States a specific verb (Returns) and resource (secondary-structure annotations) scoped to a PDB Entity ID, and enumerates the payload (helices, strands, per-residue predictions). It is clearly distinguishable from siblings like doms_ent or annot_ent by content, though it never names an alternative 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?

No when-to-use guidance, prerequisites, or alternatives are given. An agent must infer that this is the secondary-structure retrieval endpoint purely from the resource noun, with nothing telling it when another sibling (e.g. domain or annotation tools) would be the better choice.

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, destructiveHint=false and idempotentHint=false, so the read-only safety profile is covered. The description usefully discloses the return content (per-residue scores and probability distributions), which matters since there is no output schema, but says nothing about failure modes, entity validity, or data volume.

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

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

A single front-loaded sentence opening with the return verb and no filler; the content list is compact. It is slightly dense but every clause carries information.

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

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

For a read-only, two-required-parameter retrieval tool with no output schema, the description covers what is retrieved and at what granularity (per residue, per entity). It omits error/edge-case behavior and sibling differentiation, but the core contract is intact.

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% for both parameters, so the schema already defines pdb_id and entity_id fully. The description merely restates them as 'PDB entry ID and PDB entity ID' without adding format, constraint, or validity meaning beyond the schema. Baseline 3 applies.

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

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

The description gives a specific verb ('Returns') and resource ('residue-level sequence conservation data') scoped to a PDB entry and entity, plus names the payload (per-residue conservation scores, amino-acid probability distributions). It is clear on its own, but never distinguishes itself from adjacent per-entity retrieval siblings such as sec_struct_ent or var_ent.

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

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

There is no when-to-use guidance, no statement of prerequisites or validity constraints (e.g., whether the entity must exist or be a polymer), and no pointer to alternatives. The agent must infer usage purely from the tool name and description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description usefully supplements this by detailing what the response contains (conservation scores, probability profiles, identifiers, track colors), but says nothing about pagination, auth, or rate limits – acceptable given annotation coverage.

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 action and resource before enumerating the response fields. The response enumeration is slightly list-like but every clause conveys distinct returned data, so it 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?

There is no output schema, so the description correctly carries the burden of describing the return value and does so concretely. With a single fully-documented parameter and a clear return summary, an agent has enough to call it correctly; only the when-to-use aspect is missing.

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

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

Schema description coverage is 100% and there is only one required parameter, so the schema already documents it fully. The phrase 'for a UniProt accession' adds no format or syntax detail beyond what the schema states, so the baseline of 3 applies.

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

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

States a specific verb ('Retrieve') and a specific resource ('PDBe-KB sequence conservation data') scoped to a UniProt accession, which is distinguishable from sibling endpoints covering variation, binding sites, or structure. It does not, however, explicitly name or differentiate itself from any sibling tool by 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 says what the tool returns but gives no guidance on when to use it versus alternatives such as unip_var or other per-accession endpoints, nor any prerequisites or exclusions. Usage context is left entirely to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered by structured data. The description adds real behavioral value by defining the similarity criteria returned: stereoisomers, common-scaffold components, and molecules with ≥60% PARITY similarity. It omits return format/ordering, and the idempotentHint=false is left unexplained.

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

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

A single front-loaded sentence that names the operation first and then enumerates the result categories. No filler, no restatement of the title, and every clause carries information.

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

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

For a read-only, single-parameter query, the description supplies the result semantics (which similarity categories are included) that the absent output schema cannot. It is nearly complete; only result ordering, limits, or pagination behavior are unaddressed.

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

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

There is a single required parameter (hetcode) with 100% schema description coverage, so the schema already documents it. The description adds no format or syntax detail about the hetcode beyond referring to 'the given chemical component', matching the baseline 3 for schema-covered 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?

States a specific verb ('Returns') and resource ('chemical components that are similar to the given chemical component'), making the operation immediately identifiable. It does not explicitly differentiate itself from sibling ligand tools such as ligand_sum_comp_sum_hetcode or comp_in_comp_in_hetcode, so it stops short of a 5.

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

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

The description explains what results contain but never states when to use this tool versus the many sibling ligand/component tools, nor any prerequisites or exclusions. Usage is only weakly implied by the phrase 'similar to the given chemical component'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description goes further by disclosing the harmonic-mean construction and, critically, the edge-case behavior (score is 0 if any contributing percentile is 0, null if all percentiles are unavailable) plus the meaning of experiment_data_available. That is meaningful behavioral context beyond the structured fields, though it omits any hint about how the metrics are grouped in the response.

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

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

The bulleted metric breakdown is readable and reasonably compact, but it is a data dictionary rather than a front-loaded purpose statement — the first clause describes return-value math instead of what the tool does, wasting the most valuable position.

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 one read-only parameter and no output schema, the definition is nearly adequate because it explains the returned fields thoroughly. However, it never says the result is keyed to the supplied pdb_id or what the overall response shape is, leaving the agent to reconstruct the tool's contract from metric definitions alone.

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?

Only one parameter exists and schema coverage is 100%, so the schema fully documents 'pdb_id' (4-character PDB id code). The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

The text never states the tool's action (e.g., 'retrieve quality scores for a PDB entry'), it only defines what the returned scores mean. An agent can infer the resource (macromolecular structure quality metrics) from the metric names, but there is no explicit verb+resource statement and no differentiation from the many sibling entry-id 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?

There is no statement of when to use this tool versus the numerous sibling tools that also take an id. No prerequisites, no scope notes, no alternative routing guidance — the agent must infer usage entirely from the metric semantics.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial value beyond them by detailing what the response actually contains (sequence/length, residue ranges in both UniProt and PDB numbering, PDB entries, scores, confidence, links, processed start positions) — important because there is no output schema.

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

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

The purpose and filter are front-loaded in the first clause, and the remaining length is spent on return-value detail that is justified by the absence of an output schema. It is somewhat dense, but every sentence carries information.

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

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

With no output schema, the description compensates well by describing the returned record structure in detail. The main remaining gap is the unfiltered/unenumerated annotation_category values, which an agent may need to supply meaningfully.

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, giving a baseline of 3. The description adds the fact that annotation_category is an optional filter, but it does not enumerate valid categories or clarify accepted values beyond the bare schema label.

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

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

States a specific verb and resource: provides PDBe-KB annotations for a given UniProt accession, with optional category filtering. This clearly separates it from structure-oriented siblings (e.g., sec_struct, bind_sites), but it does not distinguish itself from other UniProt annotation siblings such as unip_var, unip_gen_unipdb, or llm_unip_sum, so an agent could still hesitate between them.

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 per-accession and optional-category context implies when the tool applies, but there is no explicit when-to-use/when-not-to-use guidance and no named alternative among the many UniProt/annotation siblings. Usage is inferable but not directed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the description does not contradict it. The description adds substantial detail about the returned payload (coverage numbering, mutations, resolution, ligand counts), which is genuine behavioral context, but it says nothing about pagination, size limits, or failure modes for an unmapped accession. With annotations carrying the safety burden, a 3 is appropriate.

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

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

The opening sentence is correctly front-loaded, but the response-field enumeration runs long and the closing sentence ('This endpoint provides an integrated view...') merely restates the premise without adding information. The title annotation duplicates this text verbatim, suggesting the field list is padding rather than earned content.

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

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

With no output schema, the description must describe return values, and it does so thoroughly — sequence, length, chain identifiers, coverage in both numbering schemes, mutations, resolution, ligand/entity counts, and metadata. An agent knows what it will get back. It is only incomplete in omitting usage boundaries and error 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?

Schema description coverage is 100% for the single parameter, so the baseline is 3. The description mentions 'a given UniProt accession' but adds no format guidance (e.g. accession vs. entry name) beyond what the schema already states, so it neither compensates nor regresses.

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 opens with a specific verb+resource: 'Retrieve comprehensive information on PDB structures mapped to a given UniProt accession.' That is unambiguous about what is returned and from which key. It does not, however, distinguish itself from the many UniProt/PDB sibling endpoints (unip_map, unip_var, unip_giruiru, etc.), so a 4 rather than 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools despite ~30 siblings operating on UniProt accessions and entity IDs. The agent must infer from the resource name alone that this is the PDB-mapping endpoint rather than the annotations, variants, or interaction endpoints.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description does add some payload context (residue-level array, sequence length, starting position in a processed sequence), which is genuinely useful because no output schema exists, but it omits any access, rate-limit, or not-found behavior. The idempotentHint=false on a pure read is unexplained.

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 verb+resource is front-loaded, which is good, but the text is padded with redundant clauses ('offering sequence context alongside structural and functional annotations') and describes the response in two overlapping sentences. It could be roughly half its length without losing meaning.

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

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

With one simple parameter, high schema coverage, and no output schema, the description does carry some of the return-value burden and partially fulfills it by describing the residue array and sequence length. However, the description of the payload is vague and does not let an agent predict the response shape precisely.

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

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

There is a single parameter with 100% schema description coverage, so the schema baseline is 3. The description adds nothing about the accession format or scope (e.g., canonical vs isoform) beyond what the schema already states.

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

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

The description states a specific verb and resource: retrieving interface-residue details for a given UniProt accession, which is unambiguous about what is fetched. It does not, however, distinguish this tool from closely related siblings such as to iface_res_ent_interfaces_id_entity_id or ent_iface_res_ent_iface_res_id, so an agent must infer the selection criteria.

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

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

There is no explicit when-to-use guidance, no exclusions, and no named alternatives despite many overlapping siblings (entity-based interface residue tools, sequence tools). The only hint is the trailing 'enables analysis of residues involved in protein interfaces,' which is a purpose statement, not routing advice.

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, destructiveHint=false, so the safety profile is covered structurally. The description adds genuine content-level context by enumerating what the response contains (partner names, antibody roles, observed PDB structures, self-directed flag), but says nothing about data source, coverage, or limits. Note the annotations' idempotentHint=false, which the description does not explain.

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

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

Two sentences, front-loaded with the core action and resource. The closing sentence ('This endpoint provides structural and functional context') is mild filler that restates value rather than adding information, but overall it is tight.

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

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

With no output schema, the description usefully enumerates the returned fields, which compensates well for a simple read-only, single-parameter tool. The main gap is the absence of any usage tiering among the many sibling endpoints, which is not essential to calling 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?

Only one parameter with 100% schema description coverage, so the schema carries the meaning; the description merely restates 'for a given UniProt accession'. Baseline 3 is appropriate since no additional format, validation, or resolution detail is offered 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?

States a specific verb ('Retrieve') and resource ('interaction partners for a given UniProt accession') and enumerates the returned content (names, antibody-role annotations, PDB structures, self-interaction flag). The purpose is unambiguous, though it never names or contrasts any sibling endpoint in a large family of UniProt/complex 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 implies the obvious case (you have a UniProt accession and want its interaction partners) but gives no explicit when-to-use guidance, no preconditions, and no routing to related siblings such as the complex/interface tools. An agent gets no help deciding between this and, say, interface or binding-site endpoints.

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, destructiveHint=false, and idempotentHint=false, covering the safety profile. The description adds useful return-content detail but does not disclose additional behavioral traits such as error cases, rate limits, or what happens when no mapping exists.

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

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

A single front-loaded sentence with no wasted words. It efficiently states the return scope and key output fields.

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

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

Given no output schema, the description usefully explains the return values: matched UniProt accessions, residue-level alignment ranges, and Best Chain ID metadata. It is nearly complete for a read-only lookup tool, though it could mention behavior when no mapping is found or whether multiple mappings are returned.

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 both parameters are already documented. The description mentions the PDB Entity ID scope but adds no syntax, format, or constraint details beyond what the schema 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?

States a specific verb and resource: returns UniProt mappings for a PDB Entity ID, with details on matched accessions, alignment ranges, and Best Chain ID. This clearly differentiates it from simple accession-based UniProt tools, but it does not explicitly name or compare against any sibling tool.

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

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

The description gives no guidance on when to use this tool versus the many other UniProt-related siblings. It only says what it returns, with no conditions, exclusions, or 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 destructiveHint=false, so the safety profile is covered. The description adds value by enumerating what the payload contains (variant features, disease associations, PolyPhen/SIFT predictions), which matters because there is no output schema. It does not address pagination, size limits, or why idempotentHint is false.

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

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

The purpose is front-loaded in one short sentence, followed by a response-content enumeration that substitutes for the absent output schema. The closing clause 'enabling comprehensive analysis of protein sequence variations' is filler, but overall sizing is reasonable.

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 one required parameter, no output schema, and annotations covering the read-only safety profile, the description's payload enumeration supplies the missing return-value context. Only selection guidance relative to sibling tools is absent.

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

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

Schema description coverage is 100% for the single parameter, so the schema already documents 'uniprot_accession'. The description restates it as 'a given UniProt accession' without adding format, namespace, or example guidance. Baseline 3 applies.

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

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

The first sentence names a specific verb and resource: 'Retrieve variation details for a given UniProt accession.' This clearly separates it from siblings like unip_gen_annot or unip_ipu, even though no sibling is named explicitly.

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

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

The description never states when to choose this tool over the many other unip_* siblings, nor any prerequisites or exclusions. Usage is only implied by the resource name, leaving the agent to infer 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?

Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context about the response payload (variant type, alternative sequence, evidence, cross-references, clinical/functional hits, structural-impact metadata), which compensates for the absence of an output schema. No auth, rate-limit, or edge-case caveats are given.

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

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

Two sentences, front-loaded with the core purpose before enumerating response contents. The second sentence is a long list but every element maps to actual returned data, so there is little waste.

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

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

With no output schema, the description rightly spends its budget describing the return payload, and read-only semantics are covered by annotations. An agent has enough to decide and call correctly, though it lacks guidance on picking this over the UniProt-accession variant sibling.

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 description coverage, the schema already documents both pdb_id and entity_id, including the numeric pattern for entity_id. The description adds nothing about parameter format, valid ranges, or index semantics beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb ('Returns'), a concrete resource ('UniProt sequence-variation annotations'), and the scoping mechanism ('for a specified PDB Entity ID, remapped to the entity's residue positions'). This is far more informative than a tautology and implies the entity-based nature that separates it from accession-keyed siblings. It stops short of naming a sibling tool explicitly, so it is clear but not fully differentiated.

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 never says when an agent should reach for this tool versus alternatives such as unip_var_unip_var (UniProt accession keyed) or annot_ent. Usage can only be inferred from the required PDB entity inputs, and there are no stated prerequisites or exclusions.

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