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

With no annotations, the description carries the full burden and does substantial work: it discloses that the task is persisted and returned with its id, that alarms fire at a default 3-minute lead (configurable), that alarms require a due time, and that the desktop app surfaces them. It omits error behavior for malformed syntax, tag auto-creation, and duplicate handling, keeping it below 5.

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?

Front-loaded with the one-sentence purpose, then a compact token-by-token syntax list where nearly every clause carries a distinct rule. It is dense but not padded; the only slack is that token rules are comma-joined rather than separated, which slightly slows scanning.

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 single-parameter tool with no output schema, the description covers input syntax exhaustively and states the return value ('the stored task, with its id'). Remaining gaps are failure modes and side effects on tags, which are minor for a create operation of this shape.

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?

Although schema coverage is already 100%, the description goes far beyond the schema's one-line example by fully specifying the inline mini-language: #tag, !/!! priority, the full set of due-day forms, @15:30 time semantics, @none, and @alarmN's 0–1440 range. An agent can construct a valid argument purely from this prose.

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 ('Add a task') and immediately defines the input medium ('from one line of text'). The create-vs-complete-vs-update distinction is obvious from the verb, but the description never names or contrasts any sibling tool, so it lands at 4 rather than 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?

Usage is implied by the verb — you call this when a new task must be created — but there is no explicit 'use this instead of update_task when...' guidance, no statement about prerequisites, and no mention of how to handle text that references an existing task. Adequate but inferential.

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

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

No annotations are provided, so the description carries the full load and does: it discloses snooze clearing, that a done task won't ring its alarm, where the task moves, idempotent re-completion behavior, and the exact error for an unknown id. That is unusually complete for a mutation tool with zero annotation coverage.

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?

Five short sentences, every one load-bearing: effect, side effect, state transition, idempotency, error, undo route, return shape. The primary action is front-loaded.

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 mutation with no annotations and no output schema, the description covers side effects, resulting state, repeat invocation, error behavior, and even the return value ('Returns the task'). Nothing an agent needs to call it correctly is missing.

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 100% on the single id param, so the baseline is 3; the description adds value by specifying the failure mode for an unknown id, including the exact error text. It doesn't restate id provenance, but the schema already does.

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?

Opens with a specific verb+resource ('Mark a task done now') and implicitly distinguishes itself from delete_task and reopen_task through the stated effects. An agent can tell what this does without reading the schema.

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?

Explicitly routes the undo case to reopen_task, which is the key alternative. It doesn't address when to prefer delete_task over completing, but the primary sibling decision is covered.

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

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

With no annotations, the description carries the full burden and does disclose the critical trait: "There is no undo," which is exactly the destructive-behavior warning an agent needs. It also states the return value ("Returns the removed task"), though it omits permission requirements and side effects such as whether subtasks cascade.

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 waste, with the destructive warning front-loaded right after the purpose. 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 single-parameter destructive tool with no output schema, the description covers purpose, irreversibility, and return value. Only minor gaps remain, such as permission needs or cascade behavior, which are not essential to invoke it 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?

Only one parameter (id) and schema description coverage is 100%, so the schema already documents it fully. The description adds no format or constraint detail beyond the schema, which is the expected baseline here.

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 ("Delete a task") that is unambiguous and clearly distinct from siblings like complete_task or update_task. It does not explicitly name or contrast with an alternative, but the operation is self-evidently different from the other task tools.

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?

No guidance on when to use this versus alternatives such as complete_task or update_task, nor any prerequisites or exclusions. The agent must infer that this is the hard-removal path from the name alone.

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

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

With no annotations, the description carries the full burden and does: it declares read-only semantics ('change nothing'), the serialization format, the omission rule for empty fields, and the exact failure message for an unknown id. That is more behavioral disclosure than most read tools provide.

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?

Four short sentences, front-loaded with purpose and effect, then routing, then the error case. Every sentence adds information; nothing repeats the schema or title.

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 single-parameter read tool with no annotations and no output schema, the description covers purpose, return shape, field-omission behavior, error semantics, and sibling routing. Nothing an agent needs to call it correctly is missing.

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 100% and the schema already explains where the id comes from (list_tasks, search_tasks, add_task). The description only adds the trivial 'use it when you know the id', so baseline 3 applies.

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 ('Get one task by id') plus the explicit non-effect ('change nothing'), which separates it from every mutating sibling. The return contract ('Returns the task as JSON') is stated up front.

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?

Gives the positive trigger ('Use it when you know the id') and names both alternatives with their selecting conditions: search_tasks for text lookup, list_tasks for views like today or inbox. No inference required.

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

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

With no annotations, the description carries the full burden and does well: it discloses the ordering contract for every view, the 30-day window for 'done', the open-before-done ordering for 'all', and that the return is a JSON array. It does not mention pagination, result limits, or auth requirements, which is the remaining gap for a read tool with zero annotation coverage.

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?

Purpose is front-loaded in the first sentence, followed by the view enumeration and the return type. Dense but nearly every clause earns its place; the enumeration of five views makes it long, though that length is functional rather than redundant.

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 two-parameter, zero-required listing tool with no output schema, the description covers purpose, all parameter values, ordering, and return shape. Only pagination/volume behavior and the exact task object shape are unaddressed, which are minor for 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 coverage is 100%, so the baseline would be 3, but the description adds genuine meaning beyond the schema: the schema only lists valid view strings, while the description explains what each view actually contains and how it is ordered. Filter semantics (title or tag, case-insensitive) are already in the schema and are not duplicated.

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?

Opens with a specific verb and resource ("List the tasks of one view, in the view's order") and then defines each view value precisely. It does not explicitly name a sibling such as search_tasks, but the 'view'-based framing is distinct enough that an agent can separate it from the other task tools.

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 per-view definitions effectively tell the agent which view to pick for which need (overdue work → 'today', future work → 'upcoming', undated → 'inbox', recent history → 'done', everything → 'all'). What's missing is guidance on when to use this tool versus search_tasks or get_task, but the usage context for the parameters is clear.

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

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

With no annotations, the description carries the full burden. It usefully discloses that planning does not set a due date and that the task is returned, but it omits safety profile (idempotency), error behavior for a missing or nonexistent id, and permission requirements 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?

Two sentences, both front-loaded and free of waste: the toggle semantics come first, followed by the return value. Nothing redundant against the name or title.

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?

With only 2 parameters, no nested objects, and no output schema, the description covers the core contract including the return value. Missing error-handling and permission context keeps it just short of complete for a mutation tool with no annotations.

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 100%, so a baseline of 3 applies, but the description adds meaning beyond the schema by clarifying that planning is decoupled from due dates and framing planned as a toggle between addition and removal from the Today view. The 'id' parameter is left to the schema.

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: toggling a task's membership in the Today view via planned=true/false, and returns the task. It implicitly distinguishes itself from the generic update_task sibling by naming the specific 'planned' semantics, though no sibling is named directly.

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 implies when to use each direction (plan vs unplan) through the planned flag, but gives no guidance on alternatives such as update_task or add_task, nor any prerequisites or exclusions. A capable agent can infer usage, but the routing information is left implicit.

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

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

With no annotations, the description carries the full burden and does: it scopes the mutation to the done flag only, enumerates the preserved fields (title, tags, priority, due day, plan, alarm), states idempotency for open tasks, and quotes the exact error for an unknown id. That is mutation scope, side effects, and failure mode all in one short paragraph.

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?

Four compact sentences, front-loaded with the action and its effect, followed by what is preserved, the no-op case, the alternative, and the error. Every sentence carries distinct information.

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 mutation with no output schema, the description covers the state transition, preserved state, idempotency, error contract, and return value ('Returns the task'). Nothing an agent needs in order to call it correctly is missing.

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 100% and the single parameter already documents its provenance via a sibling tool, so the baseline is 3. The description adds only the failure behavior for an unknown id, not any new semantics for the id argument itself.

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 ('Reopen a done task') plus the resulting state ('so it is open again'), which is more precise than the bare name. It explicitly distinguishes itself from the sibling complete_task, so an agent can route between them without opening a schema.

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?

Gives the trigger condition (task is done), the no-op condition (already open), and names the inverse tool ('To mark a task done, use complete_task'). Both when-to-use and the alternative are spelled out, leaving nothing to inference.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses case-insensitive matching, ordering (open tasks first), and the return shape (JSON array), but says nothing about pagination, result caps, or whether it is a safe read-only operation — gaps that matter for an unbounded 'every task' search.

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?

Four short sentences, each carrying one distinct fact — scope, matching rule, ordering, return type — with the most important information first. Nothing is redundant or padded.

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 read tool with no output schema, the description covers matching behavior, ordering, and return type, which is enough to call it correctly. It omits any mention of result limits or pagination, a minor but real gap for a search that claims to find 'every task'.

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 100% and the single parameter is documented as 'The text to look for.' The description adds genuinely new semantics: the text is matched against title OR tag, and the match ignores case. That is meaning the schema does not provide.

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 gives a specific verb and resource ('Find every task') and narrows scope to title/tag text matching, which distinguishes it semantically from list_tasks. It does not explicitly name list_tasks or get_task as alternatives, so differentiation is implied rather than stated.

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?

There is no sentence telling the agent when to search versus when to use list_tasks or get_task, and no exclusions. The text-match framing implies the use case (you have a substring, not an ID), but the agent must infer the routing decision.

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

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

No annotations are provided, so the description carries the behavioral burden and does well: it discloses that missing fields are cleared, today's plan and done state are preserved, alarms require a due time, and alarms appear in the desktop app. It leaves some operational gaps around permissions, invalid task IDs, invalid text, and error behavior.

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?

The description is front-loaded with the replacement behavior and clearing semantics, then lists the inline syntax rules in a compact sequence. Although it is long, every sentence appears to earn its place given the complexity of the text grammar.

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?

With no annotations and no output schema, the description must carry the behavior, and it largely does: mutation semantics, field clearing, preservation rules, alarm prerequisites, and return are covered. It still lacks error cases, permission requirements, and details about the returned task shape.

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 100%, but the description adds substantial meaning beyond the schema for the text parameter: words become the title, #tag adds tags, ! and !! set priority, date forms set due days, @15:30 sets due time, @none clears dates, and @alarm sets alarm lead times. The id parameter is left to the schema.

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: replace a task's title, tags, priority, due date/time and alarm from one line of text. It also clarifies scope by saying unspecified parts are cleared while today's plan and done state stay, which distinguishes it from add_task and complete_task/reopen_task.

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?

Clearly implies this should be used when replacing multiple task fields from a one-line text, and warns that missing parts are cleared. It also implicitly excludes completion tools by stating the done state stays, but it does not explicitly name alternatives such as add_task or complete_task.

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