starrail_check_alerts

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

With no annotations provided, the description carries the full behavioral burden, and it delivers on the most important trait — stateful dedup: 'a good alert fires once until the condition resets.' This is exactly the kind of behavior an agent cannot discover from the schema and must know to avoid duplicate acknowledgments on repeated polls. It also documents the silent-empty contract. It could add what 'resets,' or whether this is safe read-only, but core behavior is well covered.

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?

A single paragraph that front-loads the core behavior plus the key distinguishing feature (alerts, not full note), then dedup policy, then polling contract, then the two parameters. Every clause earns its place; there is no filler or restatement of the schema's existing types. This is an efficient, high-information structure.

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 2-parameter, no-annotation, no-output-schema polling tool it is largely complete: triggers, dedup/reset semantics, silent behavior, parameter origin, default, and omissions. The main gap is the alert payload form (there is no output schema, and the description never says what an alert object looks like when populated), so an agent cannot predict the exact return shape without probing the tool.

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 0% (both params bare with only type/null/default: null). The description compensates meaningfully at a compact level: it states where account_id comes from (accounts_list), when it may be omitted, and the stamina_threshold's semantics (default 200) plus its relation to the noteworthy threshold. Remaining gap: the inclusive/exclusive relationship between current stamina and the threshold (e.g., alert when stamina needs rest ≥ threshold) is not spelled out.

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-resource pair ('Check a Star Rail note') and the exact output contract: 'return only noteworthy changes' with named categories (stamina nearly full/full, expeditions complete, daily training complete). This clearly differentiates it from sibling starrail_daily_note (full note) and genshin/zzz_daily_note (other games) without needing to inspect schemas.

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?

'Designed for scheduled polling: empty alerts means stay quiet' explicitly states the intended invocation context and what silence means in that loop. The parameter guidance ('account_id from accounts_list; omit when only one account is logged in') also functions as usage direction. It stops short of naming the exact alternative tool (starrail_daily_note) for the 'need the full note' case, so exclusion guidance is implied rather than stated.

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