mark_day_complete

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

The description states the core mutation (marking a day complete or incomplete), which aligns with the annotations readOnlyHint=false and destructiveHint=false. It does not add richer behavioral context such as side effects on streaks or handling of non-existent days, but the annotations already provide idempotency and destructiveness safety, lowering the burden on the description.

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?

Two crisp sentences followed by a structured Args block. The purpose is front-loaded, and there is no filler or redundant explanation. Every sentence earns its place.

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 simple two-parameter mutation, the description covers the operation and all parameter meanings. The output schema and annotations cover return values and safety characteristics. It stops short of a 5 by leaving edge-case behavior (e.g., what happens if the day does not exist) unmentioned, but this is a minor gap.

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?

The schema provides only types and a default, with zero parameter descriptions. The description's Args block compensates fully by specifying the exact date format 'YYYY-MM-DD' and the boolean mapping 'True to mark complete, False for incomplete'. This gives an agent everything needed to set each parameter correctly.

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 ('mark') and resource ('diary day') with the two possible states 'complete or incomplete'. It is clearly distinguishable from all sibling tools, which deal with foods, biometrics, exercises, and fasting rather than diary completion status.

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 provides clear context for when to use the tool: whenever a diary day's completion status needs to be set. It does not explicitly name alternatives or exclusions, but no sibling tool appears to overlap this functionality, so explicit routing is unnecessary.

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