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

Annotations only declare readOnlyHint and openWorldHint=false; the description adds genuinely new behavioral context — it costs ONE rate-limit slot instead of three, and each signal returns as its own sub-envelope so one upstream failure degrades only that section. The instruction to check each sub-envelope before relying on it is operational guidance not derivable from structured fields.

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?

Front-loaded with the USE WHEN trigger, then the cost/degradation facts, then a NEXT routing hint. Every sentence earns its place and the structure maps to how an agent decides, calls, and follows up.

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 composite read tool with no output schema, the description supplies the missing return-shape information (per-signal sub-envelopes) plus failure-isolation semantics. Nothing an agent needs to call or interpret the result correctly is absent.

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%, so the schema already documents days, series, disease and include (including how each is forwarded). The description adds little parameter-level meaning beyond naming the three composable signals. Baseline 3 is appropriate when the schema carries the detail.

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 clear result — returns the MIND, Hope and Trends signals together in one call — which immediately distinguishes it from the singular siblings get_mind_signal, get_hope_signal and get_trends_signal. An agent can identify it as the batch/composite entry point without inspecting any schema.

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?

"USE WHEN you want to orient on the whole platform in one call, or you are rate-limit sensitive" gives explicit selection conditions, and the NEXT clause routes the agent to drill-down tools or search_world_trials. The rate-limit framing makes the choice against the individual signal tools unambiguous.

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