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

With no annotations, the description carries the full behavioral burden; it does disclose cost ('Free · 1 credit') and the shape of the returned record, which is genuinely useful context not available elsewhere. It never explicitly confirms read-only semantics, says nothing about pagination/truncation despite a limit parameter, and doesn't indicate how 'ready' is determined or how stale 'last built' data can be.

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 short sentences, front-loaded with what the tool returns and then the sequencing rule; the credit tag is bracketed so it doesn't interrupt the substance. The parenthetical field list is telegraphic and reads as a fragment rather than a sentence, a small clarity cost in an otherwise efficient definition.

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?

Because there is no output schema, the field enumeration is doing necessary work, and the pre-call routing hint is present. Still missing for a discovery tool with zero annotation coverage: what a 'topic' is keyed by, whether the list is exhaustive or truncated by limit, and ordering/staleness of the results — an agent can call it but can't predict what it will get back.

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 0% for the single parameter (limit, default 50, range 1–100), and the description never mentions it at all. The schema's default/min/max make the constraint partly self-evident, but the description adds no meaning — not whether limit caps topics returned, whether ordering is defined, or what happens at the cap.

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 resource — topics that have a ready expert — and enumerates the returned fields (name, layer, papers ingested, last built), so an agent knows this is a discovery/listing call rather than an expert-query call. The verb is only implied by the name 'list_experts', and 'topics' is not defined, which keeps it short of a 5.

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 gives explicit ordering guidance: call this before expert_notes / expert_ask, which is a real routing rule that tells the agent where this sits in a workflow. It does not say when to skip it (e.g., if you already know the topic) or how it relates to the other expert_* siblings, so no exclusion criteria.

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