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

With no annotations, the description carries the full burden and does add real context: it discloses that the response includes endpoint_pct and its estimand and explains why — the endpoint marker and last plotted point are distinct quantities. That is a genuinely useful disclosure beyond the schema, but nothing is said about permissions, data provenance/accuracy limits of 'digitised' values, or error behavior.

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 core purpose is front-loaded in the first sentence and the second sentence justifies the extra endpoint fields rather than padding. The rationale clause is slightly long-winded but each sentence carries information, so little is wasted.

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?

There is no output schema, so the description must describe returns, and it partially does (week-by-week points, per-dose series, endpoint_pct with estimand). However, it omits the shape of those series, units, how many points to expect, and the drug-identifier format, leaving meaningful gaps for a data-retrieval 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?

The single required parameter 'drug' has 0% schema description coverage — a bare string with no title or docs — and the description only says the curve is 'for a drug.' It never states whether the value is a name, slug, or ID, or whether fuzzy matching is supported, so the agent is left to guess the accepted format.

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 names a specific resource — the digitised week-by-week weight-loss curve for a drug, plus per-dose series — which no sibling tool provides. It is clear what data comes back, though it never explicitly contrasts itself with compare_efficacy or get_drug, so an agent must infer the split from the resource name alone.

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?

Usage is only implied: an agent can deduce this is the tool for pulling a curve, but there is no statement of when to reach for it instead of compare_efficacy or get_drug, no prerequisite for the drug identifier, and no exclusions. Nothing steers selection beyond the tool name.

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