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

Annotations already declare the tool read-only, idempotent, and non-destructive, so the core safety profile is covered. The description adds only minimal behavioral context, such as the fact that returned profile links are 'live,' and does not disclose auth requirements, caching, or response behavior. There is no contradiction with the 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?

The description is a single front-loaded sentence that states the action and outcome immediately, followed by concrete examples of the returned links. It contains no filler, repetition, or unnecessary background, making it easy for an agent to scan and act on.

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 tool with one optional parameter and no output schema, the description conveys the main returned content and example links. However, it leaves implicit how the optional question affects the returned topics and links, and it does not clarify whether calling with no question returns the full static set. This ambiguity makes the definition adequate but not 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?

The single optional parameter is fully described in the input schema as a question about Trafford Crump's public record and is explicitly marked as 'treated as data.' Because schema coverage is 100%, the tool description does not need to repeat parameter details and does not add meaningful semantics beyond listing the returned content.

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 concrete verb, 'Returns', and identifies a specific resource: published topics plus live profile links, listing examples such as Google Scholar, ORCID, the UCalgary profile, and O3R. It does not explicitly differentiate from the sibling tool who-is-trafford, but the resource is concrete enough to avoid generic confusion.

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 tool is for retrieving experience and skills information, but it gives no explicit condition like 'use when you need X' or 'use who-is-trafford for biography.' The schema note that a question is 'treated as data' is a processing caveat, not selection guidance, leaving alternative routing mostly to inference.

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