rcsb_describe_seqcoord_object

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the description adds context beyond that: every returned path is 'verified against the live schema' and therefore safe to pass to `fields=`. It also discloses that the schema bottoms out at 3 levels and that results may include `truncated` and `note` fields, giving the agent a clear model of what to expect.

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

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

The description is detailed but well-structured with Args/Returns sections, and every sentence contributes new information. It front-loads the core purpose in the first sentence, uses a compact example to convey the workflow, and avoids repetition. The length is justified for a describe tool that must clarify its relationship to the seqcoord family.

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

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

Given the tool's purpose as an introspection aid, the description fully covers behavior, parameters, return structure, and integration with sibling tools. It even notes the schema's small size and the max_depth required to flatten it fully. The output schema is already available, so the description correctly focuses on semantics rather than restating output definitions.

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

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

With 0% schema description coverage, the description carries the full burden, and it does so excellently. It explains `object_key` as a root field with shared types, `into` with concrete examples, `query` as case-insensitive matching against path and description, and `max_depth` with its range and effect. This goes far beyond the schema's bare titles and enums.

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 'Discover the fields available on a Sequence Coordinates object', which is a specific verb+resource combination. It distinguishes itself from the sibling rcsb_describe_data_object by explicitly calling itself the 'Sequence Coordinates analogue' with the same shape, making the purpose unambiguous.

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

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

The description explains when to use this tool: to find what else can be requested via the `fields=` argument of rcsb_seqcoord_* tools. It also provides concrete usage patterns (browsing, drilling with `into`, flattening with `max_depth`, filtering with `query`) and gives an example call with a follow-up to a sibling tool, which serves as both a use case and an alternative.

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