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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds valuable context beyond them: no key required, free to use, judged by the house AI with calibration pending, not news and not advice. It also enumerates what a slug lookup returns (versioned rule text, members, daily levels, event timeline, honesty box).

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 and args are front-loaded and effective, but the trailing clauses ('judged by the house AI, calibration pending. Not news and not advice; venues by code.') are cryptic asides that crowd an otherwise tight description.

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?

Covers purpose, both optional parameters, safety/cost context, and return content for a slug lookup, with annotations carrying the safety profile. No output schema exists, but the description adequately compensates by enumerating the key fields returned.

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 q and slug. The description reinforces slug behavior and the ignored-when-set interaction with q at a baseline level, but adds no syntax or format detail beyond the example slug already present in 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?

States a specific verb and resource: reading NightWatch sub-indices, defined as rule-based baskets inside a parent index, with a concrete example (US Strategic Crypto Reserve inside CMC20). It distinguishes itself conceptually from guardrail_ratings but never names that sibling explicitly.

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 clarifies that slug returns one sub-index and q filters the list and is ignored when slug is present, which implies usage. However, it never states when to choose this over guardrail_ratings or other read tools, so usage context is only implied.

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