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

Annotations already cover safety (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely non-obvious semantics: a single resolution requires an exact species-qualified symbol/ID, and provider match score alone never establishes identity. That is real policy information the agent could not get from the schema or annotations. What it omits is what comes back on ambiguity (multiple candidates vs. failure), though the output schema likely covers return shape.

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 definition is short, front-loaded with the core action, and the example earns its space by demonstrating three parameters at once. The telegraphic phrasing ("before evidence joins", "provider score alone never establishes identity") is compressed to the edge of readability, costing some clarity for the brevity gained.

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?

Annotations plus an output schema relieve the description of safety and return-value duties, and it does explain the resolution policy. Against a 4-parameter tool with a 17-value entity enum and zero schema descriptions, it is still incomplete: the assembly parameter and the behavior on unresolvable/ambiguous input are unaddressed, leaving the agent to consult the linked biomedmcp://guide.

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 must carry parameter meaning, and it partially does: the example shows `query` as a free-text symbol and `entity` as a lowercase type token, while "species-qualified" implies the species role and default. However, `assembly` (grch37/grch38) is never mentioned, and the interaction between `assembly` and genome-related entities is left entirely unexplained.

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 verb+resource is concrete: it resolves aliases/ambiguity for entities into canonical identifiers, and the example ({"entity":"gene","query":"HER2","species":9606}) makes the operation tangible. It does not name a sibling tool to contrast with, so the boundary against `search` or `get` is only implied by "Retrieve known unambiguous identifiers directly".

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?

"Resolve aliases/ambiguity before evidence joins" gives the trigger condition, and "Retrieve known unambiguous identifiers directly" gives the when-not case, effectively telling the agent to skip this tool when it already holds a canonical ID. The alternative is described by behavior rather than by tool name, so the routing requires a small inference.

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