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

Annotations cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lowered. The description adds meaningful non-schema behavior: results are ranked by supporting-publication count, each is labelled machine-extracted (not curated), the top relations carry supporting passages with PMIDs, and it's keyless. It doesn't mention rate limits or failure modes, but adds substantial context beyond annotations.

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

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

Effectively front-loaded: the verb and resource come first, followed by what is returned, then filtering, then input format and provenance. It is a single long sentence but well-organized and low-waste; the trailing provenance note earns its place given the machine-extracted caveat.

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 5-parameter, no-output-schema, keyless read tool, the description covers what the tool returns, how it's ranked and labelled, filtering options, and input formats. The main gap is not naming the sibling relation-evidence tool for those wanting just passages, but overall it is complete enough to invoke correctly.

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

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

Schema description coverage is 100% and the schema already documents every parameter including the enum, evidence_for semantics, and limit bounds. The description restates the enum values and the filter/target idea but adds little syntax or format detail beyond what the schema provides. 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+resource ('List the relations PubTator 3 has extracted') and enumerates the concrete relation patterns returned (drugs treat a disease, genes associated with a disease). It is clearly distinct from siblings like pubtator_annotations (which extracts named entities) and pubtator_relation_evidence by emphasizing the ranked list output.

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

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

Strong context: it explains the source, that filtering is available by type and second entity, and that it accepts id or plain name. However, it doesn't explicitly name the closest sibling (pubtator_relation_evidence) or state when to prefer that tool for passage-only lookups, so it falls short of full routing guidance.

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