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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, and the description does not contradict them. It usefully adds the HTTP endpoint and, most valuably, the price (10 credits, Tier 1), which the agent cannot see in annotations. However, it never explains what "stream" means here (SSE/subscription vs. one-shot snapshot) or whether repeated calls re-bill 10 credits each time, which matters given idempotentHint=false.

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?

One content sentence followed by three bracketed metadata tags — front-loaded with zero wasted prose. The tag format is scannable, though the bracketed blocks are somewhat machine-formatted rather than explanatory.

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?

An output schema exists so return-value explanation is not required, and cost/endpoint are disclosed. Still, for a streaming tool the description leaves the core operational question — whether this opens a stream, one-shot-queries the current VOC window, or both — unresolved, which is the kind of gap a costed, non-idempotent endpoint should close.

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 both optional parameters (fields, precision) are fully documented in the input schema with examples and bounds. The description adds nothing about them, and none is needed; baseline 3 applies when the schema does the work.

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?

"Current Moon VOC + next ingress" names the specific resource (Moon void-of-course period) and the exact payload (current state plus the upcoming ingress), which is more precise than the bare tool name. The [Group: Real-time Streaming] tag tells the agent this is the streaming-surface variant rather than the sibling webhook (astroway_webhooks_void_of_course_start), but that differentiation is implied by a tag, not stated.

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?

There is no when-to-use or when-not-to-use guidance. The agent gets the endpoint path and group label but nothing explaining when to pick this over the sibling astroway_webhooks_void_of_course_start or astroway_webhooks_void_of_course_start / astroway_stream_ingress, nor any prerequisite for calling it.

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