Create a HoldOn todo item to capture reminders or tasks. Use when a user asks to add a task; new items are ungrouped, then verify with todo_list.
Create a HoldOn todo. Use when the user asks to add a reminder or task. New items are ungrouped; use todo_list to verify.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Todo text, max 500 characters |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does add real behavioral context: new items are ungrouped, and todo_list is the verification path. It says nothing about what is returned (e.g., a created id), whether the call is idempotent, or any auth/permission requirement, which leaves meaningful gaps for a mutation tool.
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?
Three short sentences, zero filler, with the core action front-loaded and the usage condition and default state following immediately.
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 one-parameter create tool with a fully documented schema and no output schema, the description covers action, trigger, default grouping state, and a verification path. The only omission is any statement about the result of a successful create, which is a minor gap at this complexity level.
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% and the single parameter (content, max 500 characters) is fully documented in the schema. The description adds no further parameter meaning, so the baseline of 3 applies for a schema that does the work.
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 ("Create a HoldOn todo") that an agent can act on directly. It distinguishes the tool from todo_list by naming the verification role of the sibling, but it doesn't contrast with todo_update or todo_complete, so sibling differentiation is only partial.
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?
"Use when the user asks to add a reminder or task" gives an explicit triggering condition, and "use todo_list to verify" points to a complementary sibling. No exclusions or prerequisites (e.g., grouping requirements, duplicate handling) are given, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.