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

Goes well beyond the readOnly/idempotent/destructive annotations by disclosing the daily unique-doctor rate limit, the fact that re-opening the same doctor the same day is free, the daily_doctor_limit reply field, and the licensing/attribution terms on industry_links. It even states a behavioral constraint the tool enforces (profile text is not reproduced; hand the user the source link) that no annotation conveys.

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?

Purpose and limits are front-loaded, but the middle section becomes a long semicolon-delimited enumeration of every returned field that is hard to scan and partly duplicates what a consumer of the results would discover anyway. Still, no sentence is purely wasted given the absent output schema.

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?

With no output schema, the description carries the return-shape burden and does so thoroughly: RPPS identity, specialties, DU/DIU, practice modes, addresses/phones from RPPS and Ameli, fees and sectors, hospital FINESS, booking/video flags, source pages with read dates, and industry_links provenance. Combined with the rate-limit and licensing disclosures, an agent has everything needed to call and interpret this tool.

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% with pattern and maxItems constraints documented per property, so the schema already carries the semantics. The description's 'up to 10 at once' and 'one doctor_id' restate the schema's maxItems/minItems rather than adding format or edge-case meaning, so baseline 3 applies.

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 ('Evidence for doctors in France from search_doctors') and explicitly frames it as the follow-up detail fetch to search_doctors, so the agent can separate it from the sibling search tool without opening either schema. The opening clause also names the required inputs, making the tool's role 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?

Gives clear operating context: fetch up to 10 IDs at once or one ID, and 'Open the doctors you are seriously considering, not every result' — a real usage constraint tied to the daily cap. It names search_doctors as the ID source and explains the reuse-for-free rule, but does not spell out an explicit when-not-to-use or a hard alternative path for bulk browsing.

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