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

The annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful context beyond that: data is authoritative for CME occurrence, some fields only appear for analysed events, and the 'most accurate available' flag indicates variable analysis quality. It also explains the real-world meaning of the data without contradicting the annotations.

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 longer than strictly necessary but every sentence carries useful information: the first gives example queries, the second defines the returned fields, and the third explains the phenomenon's relevance. It is front-loaded with the user-facing question, though the NASA expansion and third sentence could be tightened without losing value.

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 does the necessary work of listing the expected return contents: start time, instruments, analyst note, speed, direction, half-angle width, and accuracy flag. Combined with complete parameter documentation and safety annotations, an agent has enough context to call and interpret the tool correctly, though exact response structure is not specified.

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 coverage is 100%, and the input schema already documents all five optional parameters, including defaults and speed interpretation. The description adds domain context around speed and direction but does not materially extend the parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 (CME catalog from NASA DONKI) and a clear action: it returns CME occurrence and geometry, including start time, instruments, source-region notes, speed, direction, half-angle, and accuracy. It opens with a concrete user query, making it easy for an agent to match this tool to the CME domain and distinguish it from sibling DONKI tools focused on geomagnetic storms, SEPs, or solar flares.

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 gives clear contextual cues for when to use the tool: 'Was there a coronal mass ejection this week?' and 'is a CME heading for Earth?'. It also explains why speed plus direction is the key signal for Earth impact. It does not explicitly name exclusions or alternative tools such as donki_geomagnetic_storms, so it falls short of the full when/when-not guidance.

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