starrail_daily_note

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the returned data surface and one behavioral condition (account_id omission when a single account is active), which is genuinely useful. It leaves unstated how the tool behaves with no account logged in, whether authentication is required, and any failure modes — gaps that are notable given the absence of an output schema and 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?

One dense, front-loaded sentence with zero waste: the first clause tells the agent what the tool returns, and the second clause handles parameter provenance and the omission rule. Every phrase earns its place given that the schema and no output schema leave the description as the primary documentation.

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 low-complexity, single-optional-parameter tool with no output schema, the description covers the essential details: what data is returned and how to source the parameter. What's missing is minimal and somewhat scoped — no explicit statement about authentication state or the single-account default behavior at runtime. Overall, an agent would likely call this correctly.

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 0%, so the description is the only source of meaning for account_id. It compensates well: it explains where the value must come from (accounts_list) and sets the cardinality rule (omit when one account is logged in). This goes beyond what the bare schema provides and gives the agent actionable semantics for the single parameter.

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 resource (Star Rail daily note) and enumerates the exact data it returns (stamina, reserve stamina, daily training, weekly rogue points, expeditions). The game name in the description, together with the tool name, lets an agent distinguish it from genshin_daily_note and zzz_daily_note, though the description doesn't explicitly name those siblings. The verb is implied rather than explicit (a 'retrieve'/'get' action is assumed), which keeps this from being a 5.

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?

Provides useful invocation guidance: account_id comes from accounts_list and should be omitted when only one account is logged in — this tells the agent exactly how to fill the parameter. However, it gives no explicit 'use this instead of X' guidance; differentiation from genshin_daily_note/zzz_daily_note and starrail_check_alerts is left to inference from the game-prefixed naming. That makes the usage guidance strong on parameter handling but weak on tool selection.

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