maps_maps_acc_cb64101d

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.