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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses side effects (recording as processed), recurring-task completion never being recorded, content immutability after completion, verification warnings, and the exact semantics of completion_recorded and error responses.

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 long but every section earns its place: a one-sentence summary, side-effect and routing guidance, parameter definition, detailed return semantics, critical limitations, and a concrete example. The structure with Args, Returns, Limitations, and Example makes the information easy to scan.

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 mutation tool with no annotations and a single parameter, the description is unusually complete. It covers when to use the tool, what side effects occur, edge cases around recurring tasks, immutability caveats, return shapes for success and failure, and includes an example call.

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 0%, so the description must compensate. The Args section adds the meaningful detail that task_id is the task's full ID, and the example supplies a concrete value. It could go further by explaining how to find the full ID or distinguishing it from a series ID, but for a single simple parameter this is adequate.

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 opens with a specific verb-resource pair: "Mark a task as completed." It then distinguishes itself from sibling tools by explaining that completing here also records the task as processed, so it does not appear in ticktick_get_unprocessed_completions and does not require ticktick_mark_completion_processed.

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 explicitly addresses when to use this tool versus alternatives: it notes that the unprocessed-completions queue is for completions made elsewhere, and states there is no need to call ticktick_mark_completion_processed afterwards. The Limitations section also instructs updating content before completing, implying the alternative of updating first.

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?

Discloses return format (success and error), behavior for naive strings, and error types (parse vs conversion). No annotations exist, so description carries full burden and meets it well.

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?

Well-structured with clear sections (Purpose, Args, Returns, Usage Guide, Example). Each sentence adds value; front-loaded with main purpose.

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?

Tool has 2 simple parameters, output schema described in text. Description covers all necessary details for correct invocation and error handling.

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 has 0% coverage, but description fully explains each parameter with examples, including handling of naive strings for datetime_iso_string and IANA conventions for tz.

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?

Description clearly states it converts ISO 8601 datetime to TickTick's format, specifies the output format, and distinguishes itself from sibling tools that already perform this conversion internally.

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 says when to use this tool (when setting startDate/dueDate manually) and notes that create/update tools do this internally, providing clear context for usage.

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 provided, the description fully carries the behavioral burden and does so richly. It discloses the builder() limitation that can omit fields and the re-population behavior, explains the _verification_warnings return mechanism, and describes failure responses, giving the agent a strong model of what happens when the tool is invoked.

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 long but every section earns its place for a 14-parameter creation tool. It is organized into Args, Returns, Limitations, Agent Usage Guide, and Example, with the core purpose front-loaded in the first sentence and details logically grouped.

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?

Given the tool's high complexity, zero annotations, and 14 parameters, the description covers all required invocation knowledge: parameter semantics, constraints, return shape, failure format, known limitations, and a realistic example. Nothing essential for correct use 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 description coverage is 0%, so the description must compensate entirely for the bare input schema. It does: every parameter is explained with types, defaults, formats, and constraints, including priority value mapping, RRULE syntax, reminder trigger strings, timezone defaults, and the expected_day_of_week requirement. This is far beyond what the schema provides.

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 opens with 'Create a new task,' a specific verb and resource that clearly identifies the operation. It is unambiguously distinct from sibling tools like ticktick_update_task, ticktick_complete_task, and ticktick_delete_tasks, and the detailed parameter list reinforces the creation scope.

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 Agent Usage Guide provides concrete invocation guidance, including the mandatory pairing of due_date with expected_day_of_week and how to resolve project_id via ticktick_get_all. It does not explicitly state when not to use this tool versus alternatives, but the creation-specific purpose makes the primary usage context 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 fully carries the transparency burden. It discloses error behavior for empty input, partial success warnings, project_id name/ID resolution rules, and the 'not_found' return variant. This is comprehensive for a delete operation.

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 well-structured with Args, Returns, Agent Usage Guide, and Example sections. It is slightly verbose but every section adds meaningful detail, and the example clarifies usage without being 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?

Given the absence of annotations and minimal schema descriptions, the description covers all essential aspects: parameter semantics, edge cases, return formats, and conditional usage. It is fully sufficient for an agent to select and invoke the tool 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?

The schema provides only titles with zero description coverage, but the description thoroughly explains both parameters: task_ids type flexibility and empty-list error, plus project_id's optional fallback behavior and name/ID acceptance. This far exceeds schema information.

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 opens with 'Delete one or more tasks,' which uses a specific verb and resource, clearly distinguishing it from sibling tools like ticktick_complete_task or ticktick_update_task. The scope is unambiguous.

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 'Agent Usage Guide' explicitly states when to supply project_id (for completed tasks) and explains that get_by_id does not see completed tasks. This gives clear context for a nuanced scenario, though it does not explicitly contrast with alternative deletion-like tools.

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 provided, the description carries the full burden and meets it: it discloses local-vs-live data sources, throttle-window freshness, strict validation failures ("any key not on this list is an error"), truncation with a _truncation_note, the error envelope format, and the project_list_unverifiable retry case. Nothing is dropped silently and side effects are clearly absent.

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 long, but the length is justified by the bare schema and the tool's genuine complexity, and it is well organized with headers, bullet lists, and a dedicated Agent Usage Guide. Minor redundancy — the truncation note and throttle window appear twice — keeps it from a perfect score.

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 complex filtering tool paired with an almost-empty input schema and no annotations, it is exceptionally complete: full parameter semantics, validation and error contracts, freshness behavior, server-side caps, client-side filtering caveats, and three worked examples. The Returns section even documents the truncation and error shapes despite an output schema being present.

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 0% (filter_criteria has no type at all), so the description must fully compensate — and it does, documenting every recognized key with types, defaults, allowed values (priority 0/1/3/5), strict type rules (string "3" and float 3.0 rejected), date/timezone validation, and which keys apply to which status. The detail parameter's compact/full trade-off is also precisely explained.

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 — "Return the tasks matching every supplied filter criterion" — making the tool's role immediately clear. The Agent Usage Guide examples and cross-references (e.g., to ticktick_get_by_id, ticktick_update_task, ticktick_sync) further set it apart from its siblings.

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 tells the agent when to use alternatives: fetch full objects with ticktick_get_by_id before editing, send every field back via ticktick_update_task, and call ticktick_sync to force a refresh when local state may be stale. Three concrete invocation examples with JSON show exactly when this tool should be chosen.

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 provided, the description fully discloses behavior: return values for each search type (including the inbox prepended for projects), the limitation that tasks returns None, and error handling for invalid search types. It explains the detail parameter's inertness.

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 structured with sections (Args, Returns, Limitations, Example) but is somewhat verbose. However, every sentence adds value, and the key information 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?

Given the complexity (multiple search types, quirks), the description is fully complete. It explains return values, limitations, and error handling, and references sibling tools for alternatives.

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%, but the description adds extensive meaning: explains the search parameter options and behavior of detail (accepted for parity, no effect on projects/tags). The example clarifies usage.

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 clearly states the tool dumps all items of a single kind (tasks, projects, tags) from local sync state. It differentiates from sibling tools like ticktick_filter_tasks and ticktick_get_tasks_from_project by specifying what this tool does that others don't.

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 explicitly advises when to use this tool (to get all items of a type) and when not to (for tasks, due to limitations, recommending ticktick_filter_tasks instead). It also notes the detail parameter is accepted for parity but has no effect on some searches.

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 provided, the description carries the full burden, and it delivers. It discloses the empty-object return for missing IDs, the error envelope on failure, and the critical cache-freshness behavior with a sync threshold and a remedy. This goes well beyond what the tool name or schema reveals.

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 organized into useful sections: Args, Returns, Freshness, and Example. Every sentence adds value, especially the actionable 'Branch on emptiness' and the sync threshold. It is thorough without being 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 single-parameter lookup tool with an output schema already present, the description covers everything needed to call it correctly: what the parameter means, what success looks like, what failures look like, and how staleness can affect results. No critical guidance 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 0%, so the description must compensate. It explains that obj_id is 'The object's full ID,' adds the expected type, and provides a concrete example with a valid-looking ID. This gives the agent more semantics than the bare schema's 'Obj Id' title.

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 opens with a specific verb and resource: 'Look up any object (task, project, tag) by its ID.' This clearly distinguishes the tool from siblings like ticktick_get_all and ticktick_get_tasks_from_project because it is the generic ID-based lookup. The scope is explicit and actionable.

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 makes the primary use case clear: call this when you have a full ID and need that specific record. It also tells the agent to call ticktick_sync when a fresher result is needed, which is a useful usage condition. It stops short of explicitly naming alternatives or stating when not to use this tool, so it earns a 4 rather than a 5.

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 provided, the description carries the full burden and succeeds: it discloses truncation behavior with _truncation_note, sync throttle window, completed-task exclusion, and API behavior that wipes omitted fields on updates. These are actionable behavioral traits beyond schema/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?

The description is organized into Args, Returns, Limitations, Freshness, and Example sections. Each sentence provides necessary information without filler; the length is justified by the tool's complexity and the absence of schema/annotation support.

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?

Given the tool's complexity, the description covers purpose, all parameter semantics, return types, failure format, edge cases (duplicate names, truncation), freshness guarantees, and an example. It fully equips an agent to invoke and interpret results 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%, but the description fully compensates: project_id semantics include name-or-ID, case-insensitivity, trimming, 'Inbox' resolution, duplicate-name error, and how to list projects. The detail parameter is thoroughly explained with exact compact/full payload differences and contentPreview behavior.

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 opens with 'Return every open task in a project,' a specific verb and resource that clearly states the tool's purpose. It also distinguishes from siblings by explicitly noting completed tasks are not included, and the compact/full distinction adds further scoping.

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 Limitations section explicitly references alternatives: use ticktick_get_by_id for full task content/editing, ticktick_update_task for updates, ticktick_get_all for listing projects, and ticktick_sync for forced refresh. It also warns that compact output is for browsing only, giving clear when-to-use vs when-not-to-use guidance.

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 provided, the description carries the full behavioral burden, and it delivers. It clearly explains the unprocessed state, the downstream marking step, why tasks completed via ticktick_complete_task are excluded, and subtle recurring-completion behavior. These details go well beyond a simple 'returns tasks' statement and give the agent an accurate mental model of side effects and data provenance.

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 organized into clear sections (description, args, returns, usage guide) and every sentence adds value. The key semantics are front-loaded, the parameter meanings are thorough, and the usage guide is practical without being 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?

Given the two-parameter schema, zero annotation coverage, and output schema presence, the description is complete enough for correct invocation. It covers the return shape, error format, parameter semantics, workflow context, and edge cases such as duplicate project names and recurring completions. An agent can confidently select and call this tool based on the description alone.

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 0%, so the description must compensate fully, and it does. project_id is documented as required and accepts an ID or a case-insensitive, trimmed name with 'Inbox' resolution and an explicit duplicate-name error. days is given a precise meaning ('How many days back to look for completions') and its default of 30 is stated. The included example further clarifies invocation.

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 opens with a precise, specific statement: 'Returns completed tasks for a project that have NOT yet been marked as processed by a domain agent.' It clearly identifies the resource (completed tasks), the condition (unprocessed), and the scope (per project). It also distinguishes itself from related tools like ticktick_complete_task and ticktick_mark_completion_processed by explaining what it does and does not include.

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 explicitly tells the agent when to call it ('at the beginning of each conversation'), how often ('Call once per project'), and what to do after each invocation ('call ticktick_mark_completion_processed'). It also gives an explicit exclusion: tasks completed through ticktick_complete_task are already recorded, so this tool targets completions from outside the MCP workflow. This is strong, actionable routing guidance.

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?

Since no annotations are provided, the description carries full burden. It documents success and error states (not_found, cross-project), but does not discuss idempotency, side effects on parent task order, or authorization requirements.

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 concise with structured sections (Args, Returns, Example) and includes an example. Every sentence adds value without unnecessary fluff.

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?

Given the tool's simplicity, the description covers purpose, constraints, and error handling. However, it omits edge cases like what happens if the child is already a subtask elsewhere, and assumes output schema covers return structure.

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?

With 0% schema description coverage, the description provides clear, meaningful definitions for both parameters (parent_task_id and child_task_id), including the critical constraint that they must differ and be in the same project.

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 clearly states the verb 'nest' and the resources 'child_task_id under parent_task_id', distinguishing it from sibling tools like move_task or update_task. The example further reinforces the purpose.

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 constraints (must differ, same project) and error cases, but does not explicitly compare to alternatives like ticktick_move_task or when to use subtasking vs. other organizational methods.

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 discloses key behaviors: the task will no longer appear in future calls to the companion tool, and it documents all return statuses (ok, already_processed, error). It also warns about ambiguous project names being an error, adding important behavioral detail.

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 well-structured with Args, Returns, and Usage Guide sections. It is front-loaded with the purpose and each section adds value; the example is illustrative without being 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?

Covers purpose, when to use, parameter semantics, return values, and behavioral side effects. The output schema exists but the description already explains the return format, and it fully compensates for the empty schema descriptions.

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 0%, so the description's detailed parameter documentation is essential. It explains each parameter including project_id resolution rules (case-insensitive, trimmed, 'Inbox' special case, duplicate name error), and clarifies optional fields like title and completed_time.

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 begins with a specific verb+resource: 'Records that a domain agent has processed a completed task.' It clearly differentiates from sibling tool ticktick_complete_task by noting it should be called after reviewing tasks from ticktick_get_unprocessed_completions.

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 instructs to call 'after reviewing each task returned by ticktick_get_unprocessed_completions' and includes a usage guide with 'Call once per task after finishing your handling of it.' This provides clear when-to-use guidance and references the relevant sibling tool.

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 provided, the description fully carries the behavioral disclosure burden. It details return values, error cases (not_found, error), and the edge case where the target project cannot be looked up locally (move still attempted). Project name resolution behavior is also clearly explained, covering case-insensitivity, trimming, Inbox resolution, and ambiguity errors. This is comprehensive transparency.

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 well-organized with a one-line summary, Args, Returns, and Example sections. Every sentence adds value: parameter details, behavior, error handling, and a concrete example. No redundancy or fluff; the structure is front-loaded and scannable.

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 move tool with no annotations and an output schema present, the description covers all necessary aspects: parameter semantics, return format, failure modes, and an example. It is complete even without relying on the output schema, and the explicit return behavior gives the agent full confidence in invoking the tool.

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 input schema provides no descriptions (0% coverage), only parameter names and types. The description adds rich meaning: task_id is the full ID, new_project_id accepts either ID or name with specific matching rules and error conditions. This fully compensates for the schema gaps.

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 begins with a clear, specific verb and resource: 'Move a task into a different project.' This directly distinguishes it from sibling tools like update, complete, or delete. The purpose is immediately understandable and unambiguous.

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 gives clear context on when to use the tool (to move a task to another project) and provides detailed behavioral guidelines for the new_project_id parameter (name resolution, case-insensitivity, Inbox handling, ambiguity errors). While it doesn't explicitly mention alternatives or exclusions, the purpose is distinct enough among siblings that an agent can infer appropriate usage.

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 burden. It fully discloses behavior: on success returns synced status with counts, on error returns an error detail and notes that stale state is still served. It also mentions the auto-refresh mechanism of read tools.

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 well-structured, with a clear statement, contextual explanation, return value specification, and an example. Every sentence adds value, and it is front-loaded with the core purpose.

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?

Given the tool has no parameters and an output schema exists (indicated by context), the description provides a complete picture: purpose, usage context, return format, and error handling. Nothing essential 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?

The tool has no parameters, and schema coverage is trivially 100%. According to guidelines, baseline is 4 for zero parameters. The description adds no parameter info, but it does provide context about return values and behavior, which is appropriate.

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 clearly specifies the tool's purpose: forcing an immediate refresh of TickTick state from the server. It distinguishes itself from sibling tools by contrasting with the auto-refresh behavior of read tools, leaving no ambiguity about what the tool does.

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 explicitly states when to use this tool (immediate refresh needed, e.g., after changes in the TickTick app or stale reads) and implicitly when not to (relying on auto-refresh of read tools). It also explains that the read tools auto-refresh with a configurable TTL, providing clear guidance.

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 provided, the description carries the full behavioral burden and does so thoroughly: it reveals the destructive API behavior, the fetch-then-overlay mechanism, read-only fields being stripped, and the side effect that setting status: 0 clears local completion records. It also explains the meaning of _verification_warnings and failure responses.

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 long but densely informative and well organized with Args, Returns, Limitations, Agent Usage Guide, and Example sections. It is front-loaded with the most critical fact—the update-merge behavior—and each section earns its place by explaining a real operational pitfall.

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?

Given the tool's complexity—API replace semantics, conditional field requirements, side effects on completion records, and verification warnings—the description covers every essential aspect an agent needs to call it correctly. The output schema exists, so not describing return values in detail is acceptable, and the failure format is explicitly covered.

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, and it does: it states id is mandatory, all other task_object fields are optional, only explicitly set fields are changed, and dueDate requires expectedDayOfWeek. The concrete reschedule example further clarifies how the parameters combine, and the status-0 limitation gives behavioral meaning to a parameter value.

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 first line states a specific action and resource: 'Update an existing task without wiping unmodified fields.' This distinguishes it from siblings like create, delete, complete, and move, and the merge behavior is a defining feature. An agent immediately knows what the tool is for.

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 Agent Usage Guide explicitly says to reschedule a task by sending a single update with the new dueDate and expectedDayOfWeek, and warns 'Do NOT complete and recreate.' This gives concrete when-to-use guidance and names the anti-pattern to avoid, which is strong alternative differentiation even without enumerating every sibling.

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