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

Annotations already declare readOnlyHint=true, so safety is known. The description adds valuable context beyond this: the z-scoring methodology, the 90-day window and 4,000-trial baseline, daily updates, and the exact fields returned. It does not mention advanced behaviors like rate limits or permission nuances, but the read-only hint lowers the bar; the added context justifies a 4.

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 two sentences, front-loaded with the core output and methodology, followed by explicit use cases. It is somewhat dense with numbers and field names, but every sentence earns its place. It could be slightly streamlined, but it remains focused and efficient.

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 explain return values—it does, by listing four field names and the computation method. It also covers update frequency and use cases. It lacks interpretation guidance (e.g., meaning of risk_level bins), but the complexity is moderate and the provided information is sufficient for most invocation decisions.

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 schema fully documents the only parameter 'days' with a clear description (history vs snapshot, Gold tier requirement, up to 5 years). The description itself does not mention this parameter, but since schema coverage is 100%, the baseline of 3 applies. The description adds no extra parameter semantics beyond the schema.

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 specific verb ('returns'), a clear resource (clinical-trial attrition risk score), and a precise scope (EU, based on halted/suspended counts in a 90-day CTIS window). It also lists the returned fields, making the tool's function unmistakable and distinguishing it from generic risk tools.

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 explicitly names when to call this tool: 'when the user asks about halted or suspended trials, EU pipeline health, or drug-development risk, or when timing CRO capacity...' This is strong contextual guidance. However, it lacks explicit exclusions or comparisons to alternatives, so it doesn't fully earn a 5.

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