set_todo_done

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

With no annotations supplied, the description carries the full behavioral burden. It does disclose one meaningful side effect — the completion date is taken from the phone's current calendar date — but says nothing about what happens when the todo is already in the requested state, whether the call is idempotent, or what is returned.

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 short sentences with no filler, and the primary operation is stated first with the reverse operation immediately after. The second sentence about the completion date is terse to the point of being slightly cryptic, but nothing is wasted.

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 state-toggle with no output schema and no annotations, the description covers the core semantics and one notable side effect. Missing are only edge-case behavior and the identifier source, which are modest gaps for a tool this simple.

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 must compensate for two undocumented parameters. It fully explains the done flag including both branch semantics, but leaves the required id parameter's format (a todo identifier, presumably from list_todos) entirely unexplained.

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 names a specific verb and resource ('把待办标记完成' — mark a todo done) and enumerates both directions of the toggle via done=true/false. It does not explicitly distinguish this dedicated toggle from the sibling update_todo, which likely can also set the done field, so it falls short of full sibling differentiation.

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 two boolean branches imply when to call it (marking complete vs. reverting to incomplete), which is useful implied usage guidance. However, there is no explicit statement about when to prefer this over update_todo, nor any prerequisite or idempotency note.

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