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

No annotations are provided, so the description must disclose behavioral traits. It only repeats schema requirements (title, project_id) and does not mention atomicity, partial failure handling, rate limits, or validation behavior. This is a significant gap for a batch 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?

Two concise sentences with no irrelevant content. Information is front-loaded and easily 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?

Given the complexity of a batch operation, the description lacks crucial context such as error handling, whether the operation is atomic, or any post-conditions. The lack of output schema and annotations further increases the need for descriptive completeness, which is not met.

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%, so the schema fully documents parameters. The description's mention of required fields is redundant and adds no new semantic meaning. 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?

The description clearly states a specific verb ('Create') and resource ('multiple tasks'), explicitly indicating batch creation. This distinguishes it from the sibling tool 'ticktick_create_task' by emphasizing 'at once'.

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 phrase 'Create multiple tasks at once' implies that this tool should be used when multiple tasks need to be created, differentiating it from single creation. However, there is no explicit guidance on when to prefer this over alternatives, nor any exclusion criteria, leaving room for ambiguity.

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 convey behavioral traits, but it only mentions recording a check-in and the date default. It does not disclose what happens if a check-in already exists for that date, whether the habit must already exist, or what the tool returns. The phrase 'by default' is also ambiguous given that the schema marks date as required.

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 a single, front-loaded sentence that states the action and gives the essential date format hint. Every word earns its place, with no redundancy or filler.

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?

This is a mutation tool with no annotations and no output schema, so the description must compensate for missing behavioral and return-value information. It does not mention what a successful check-in returns, how to handle duplicate check-ins, or that value is only for quantitative habits. The schema covers parameters, but the overall description leaves important operational gaps.

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%, so parameter semantics are already provided. The description adds a default-date convention for the date parameter, but this is somewhat inconsistent with the schema requiring date. It does not add meaningful insight for habit_id or value beyond what the schema already states.

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 action ('Record a check-in') and the resource ('for a habit on a specific date'). It distinguishes this from sibling tools like ticktick_get_habit_checkins (read vs. write) and ticktick_create_habit (creates a habit, not a check-in). The date format hint also clarifies the expected input format.

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 is given on when to use this tool versus alternatives such as ticktick_get_habit_checkins or ticktick_create_habit. The only usage-related hint is 'Use today's date in YYYYMMDD format by default,' which concerns the date parameter, not tool selection.

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 full responsibility for disclosing behavioral traits. It only states the core action, but omits side effects such as whether completion is reversible, any permission requirements, or how it interacts with subtasks or other task states.

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 a single, front-loaded sentence with zero wasted words. It efficiently conveys the tool's purpose without any redundant 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 simple mutation tool, the description is inadequate. It does not mention any contextual details such as task existence requirements, behavior if the task is already completed, or any post-completion effects. The lack of annotations and output schema further increases the need for richer contextual description.

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%, with clear descriptions for task_id and project_id. The description adds no additional parameter information, so the baseline score of 3 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 'Mark a task as completed' clearly states the specific action and resource, distinguishing it from sibling tools like update_task or delete_task. It is not a tautology and provides immediate understanding of 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 provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or relationships with sibling operations like updating a task or moving it to a different status.

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 of behavioral disclosure. It states the action and project type but doesn't mention permissions, return value, behavior on duplicate names, or how sort_order affects column ordering. This is minimal behavioral context 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?

The description is a single, concise sentence with no fluff or redundancy. It is front-loaded with the verb 'Add' and includes the necessary target resource and scope, earning a top 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 simple create tool with fully documented parameters, the description is adequate but not complete. It omits the return value, the implication of sort_order (e.g., appending vs reordering), and any error conditions. However, the tool's simplicity and clear schema prevent it from being severely incomplete.

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 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds no additional parameter meaning (e.g., that sort_order controls column position), but the schema already documents the parameters sufficiently.

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 uses a specific verb 'Add' with a clear resource 'column' and scope 'kanban-view project', making it distinct from sibling tools like ticktick_create_project and ticktick_create_task. It exactly matches the tool's name and title.

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 the tool (when needing to add a column to a kanban project) but provides no explicit alternatives or exclusions. It doesn't reference related tools like ticktick_delete_column or ticktick_get_columns, leaving usage context merely implied.

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 must disclose side effects and behavior. It only says 'Create a new habit' and lists fields, without mentioning permissions, return value, error conditions, or side effects. It also omits two parameters (step, section_id) from the description, reducing 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?

A single, front-loaded sentence with no fluff. It clearly communicates the action and key fields in ~20 words, earning 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?

With 8 parameters, no output schema, and no annotations, the description is too sparse. It omits two parameters, does not state the required field (name), and provides no information about the return value or side effects. The schema covers parameter definitions, but the description fails to give operational context.

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 has 100% parameter description coverage, so the baseline is 3. The description adds no new meaning beyond the schema; it merely repeats a subset of field names without additional detail. It does not explain the omitted step and section_id parameters.

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 action and resource: 'Create a new habit.' It lists the key fields, distinguishing it from other create tools like create_task or create_project. The name and title reinforce 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 context is clear: use this tool when you want to create a habit. It does not explicitly mention alternatives or exclusions, but the tool name and sibling context (e.g., ticktick_get_habits, ticktick_delete_habit) make the intended usage obvious.

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 must disclose behavioral traits. It states the operation and configurable fields, but does not mention potential side effects, permissions required, idempotency, or the response format, leaving the agent uncertain about the operation's implications.

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 two sentences, front-loads the main verb and object, and avoids unnecessary detail. Every word 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?

With no output schema and no annotations, the description does not explain the return value or any post-creation behaviors. It covers the input parameters but leaves the agent without expectations for what happens after the 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?

The input schema has 100% coverage with descriptions for all four parameters. The description essentially repeats these parameters (name, color, view mode, kind) without adding new syntactic or semantic details. It does clarify that a project is a 'list,' which is a minor addition.

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 action ('Create a new project') and the resource ('in TickTick'), distinguishing it from sibling tools like ticktick_update_project and ticktick_delete_project. It is a specific verb+resource statement.

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 explains what can be specified (name, color, view mode, kind) but does not explicitly state when to use this tool versus alternatives like ticktick_update_project. The context of creation is clear, but no exclusions or alternative guidance is provided.

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, and the description does not disclose any behavioral aspects such as whether the folder name must be unique, whether it's destructive, or what response to expect. It only states the basic action.

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 a single, focused sentence that immediately conveys the tool's purpose. It contains no unnecessary words and is front-loaded with the action verb.

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 is minimal but lacks context about folder hierarchy, permissions, or how folders relate to projects. It does not explain when to use this tool or what happens on success or failure, so it is incomplete for an agent to make an informed decision.

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?

Both parameters are described in the JSON schema, so schema coverage is 100%. The description does not add any parameter-specific semantics beyond what the schema already provides, so the baseline of 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?

The description clearly states the action (create) and the resource (a new folder) with its purpose (to organize projects). It distinguishes from sibling tool ticktick_create_project by explicitly using 'folder', making it 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 provides no guidance on when to use this tool versus alternatives like ticktick_create_project or ticktick_move_project_to_folder. It does not mention prerequisites or typical scenarios.

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 only states the action without disclosing behavioral traits such as whether duplicate names are rejected, whether the tag is immediately usable, or any side effects. The description adds minimal behavioral context beyond the action itself.

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 a single sentence that efficiently states the core purpose. It is front-loaded and contains no filler, earning its place despite being brief.

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 simple 2-parameter tool with full schema coverage and no output schema, the description is adequate but incomplete. It does not mention return values, error behavior, or uniqueness constraints, which could be useful for an agent invoking 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?

Schema coverage is 100% with both parameters described ('Tag name' and 'Tag color hex string, e.g. #FF6F61'). The description repeats the optional color but adds no new meaning. Baseline 3 applies since the schema already documents the parameters well.

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 action ('Create') and the resource ('a new tag'), and distinguishes it from sibling tools like rename_tag, delete_tag, and merge_tags. The mention of optional color adds specificity without ambiguity.

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 the tool should be used to create tags, but it does not explicitly state when to use it versus alternatives, any prerequisites, or when not to use it. Context from sibling tools suggests the intended scope, but exclusions are not stated.

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 burden. It discloses required parameters and optional fields, including the priority scale, but omits side effects (e.g., notifications sent), permission requirements, or error behavior. It provides some transparency but not a full behavioral picture.

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 well-structured sentences: the first states the core action, the second covers requirements and options. Every sentence earns its place with no redundancy.

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 13 parameters, the schema handles individual parameter details. The description provides the essential context (required vs optional) and an overview of capabilities. It could mention return values or success/failure behavior, but the lack of an output schema doesn't cripple it. Slightly incomplete for a complex create 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?

Schema coverage is 100% with each parameter described, so the baseline is 3. The description adds minimal extra meaning beyond grouping options into categories (content, dates, reminders, etc.), which is already captured in 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?

The description clearly states 'Create a new task in TickTick' with a specific verb and resource. It also names required fields (title, project ID) and lists optional features, distinguishing it from sibling tools like ticktick_update_task and ticktick_batch_create_tasks.

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 indicates when to use it (to create a single task) and what's required, but it doesn't explicitly contrast with alternatives such as ticktick_batch_create_tasks for creating multiple tasks at once. This leaves some ambiguity but the context is clear enough.

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 bears full responsibility for behavioral disclosure. It specifies the included categories but does not describe the output format (e.g., separate sections vs. combined list), sorting, or what constitutes 'high-priority'. While the read-only nature is implied by 'Get', it is not explicitly stated.

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?

Description is two sentences, front-loaded with the purpose and immediately followed by a use-case hint. No filler or redundant 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 zero-parameter tool with no output schema, the description adequately covers what the tool does and when to use it. Could optionally explain how the digest is structured or how 'high-priority' is determined, but it is not essential for invocation.

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 zero parameters, so the schema provides no parameter semantics to cover. The baseline score of 4 applies; the description does not need to add parameter details.

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 returns a productivity digest containing overdue tasks, tasks due today/tomorrow, and high-priority items. The verb 'Get' and specific content list make the purpose unambiguous, distinguishing it from sibling tools that query individual categories.

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 phrase 'Great for morning planning' provides a clear use case, but it does not explicitly contrast with calling sibling tools like ticktick_get_overdue_tasks or ticktick_get_tasks_due_today individually. No when-not-to-use guidance is given, but the context 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 must carry the behavioral disclosure burden. It only states the deletion action and does not reveal what happens to tasks within the column, whether the operation is reversible, or any side effects, leaving significant uncertainty.

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 a single, clear sentence that front-loads the action and object without any unnecessary wording.

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?

The tool is relatively simple, and the schema covers parameters, but the description omits important context about the consequences of deleting a column (e.g., what happens to its tasks) and the expected return value. This leaves the description merely adequate rather than fully complete.

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 100% coverage for both parameters (column_id and project_id), so the description adds no extra semantic value beyond the schema. Baseline 3 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 states 'Delete a column from a kanban-view project' with a specific verb and resource, distinguishing it from siblings like get_columns and create_column.

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 is provided on when to use this tool versus alternatives, such as moving tasks out of the column first or checking if the column is safe to delete. The context is implicitly understood but lacks any explicit usage direction.

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?

The description explicitly states 'This cannot be undone,' which is the most critical behavioral trait for a delete operation. Since no annotations are provided, the description carries the full burden and adequately discloses irreversibility. It doesn't mention permissions or cascading effects, but the primary hazard is covered.

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 two short sentences with zero waste. It front-loads the action and parameter, then adds the key warning. Every word 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 tool with one parameter, no output schema, and no nested objects, the description is fully sufficient. It covers the operation, the parameter, and the irreversible consequence. There is no ambiguity that would prevent correct invocation.

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 already describes habit_id as 'Habit ID to delete' with 100% coverage. The description's phrase 'by its ID' simply repeats the schema. No additional meaning is added, so baseline 3 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?

Description clearly states 'Delete a habit by its ID' – a specific verb and resource, and explicitly mentions the identifying parameter. This distinguishes it from sibling delete operations like delete_project and delete_task by naming 'habit' as the target.

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 use case is implied: use when you need to delete a habit. However, there is no explicit guidance on when not to use it, prerequisites, or how it differs from other delete tools. Among many delete siblings, no alternatives or exclusion criteria are given.

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 the burden of behavioral disclosure. It clearly states that the action is permanent ('cannot be undone') and cascades to all tasks, which is critical context beyond the tool name. However, it does not mention permissions or return behavior, leaving some gaps.

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 two concise sentences, front-loaded with the primary action and followed by a warning. Every word earns its place, with no redundant 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 simple destructive tool with one parameter and no output schema, the description adequately covers what it does, the scope of the deletion, and its irreversibility. It could mention prerequisites or confirmation requirements, but the core context is sufficient.

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 100% coverage for the single parameter project_id with a clear description. The tool description adds contextual scope (deletes tasks) but does not add new parameter-level semantics, so a baseline score of 3 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 states 'Permanently delete a project and all its tasks' with a specific verb (delete), resource (project), and scope (all its tasks), clearly distinguishing it from sibling tools like delete_task or update_project. It 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 description implies when to use the tool (when you want to permanently delete a project), but it does not explicitly mention alternatives or provide exclusion criteria. It is clear enough for basic use but lacks direct guidance on when not to use it or how it compares to delete_task.

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 discloses the critical behavioral nuance: projects inside the folder are ungrouped, not deleted. This is the most important side effect of deleting a folder. It could additionally mention irreversibility, but the core behavior is well covered.

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 a single, front-loaded sentence that states the purpose and the key behavioral caveat. Every word earns its place, with no redundant 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?

The tool is simple (one parameter, no output schema), and the description fully covers its function and the behavior of enclosed projects. No further context is needed for an agent to correctly select and invoke 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 schema already provides 100% coverage for the only parameter folder_id with the description 'Folder ID to delete.' The tool description adds no additional meaning beyond the schema, so the baseline of 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?

The description clearly states a specific action: 'Delete a project folder.' It also differentiates from the sibling tool ticktick_delete_project by noting 'Projects inside will be ungrouped, not deleted,' which prevents agent confusion about which deletion tool to use.

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 by stating the tool's effect (folder removed, projects ungrouped), implying when it should be used. It does not explicitly name alternatives or say 'when not to use,' but the behavior clarification effectively guides tool selection among siblings.

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 goes beyond a simple 'delete' by disclosing the critical side effect that tasks with the tag will have it removed. This adds meaningful behavioral context, though it does not mention reversibility or permissions, which would make it fully transparent.

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 extremely concise, with two short sentences. The first sentence front-loads the primary action, and the second adds necessary side-effect detail. There is no wasted wording.

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 delete operation with one parameter and no output schema, the description is largely complete. It explains the core operation and the impact on tasks, which covers the main context. It could mention what happens if the tag doesn't exist, but that's a minor gap given the tool's simplicity.

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 has 100% coverage for the single parameter 'name' with description 'Tag name to delete'. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 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 states the action 'Delete a tag' with a specific resource, and the added sentence 'Tasks with this tag will have it removed' clarifies the scope and effect, distinguishing it from sibling tools like rename or merge.

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 does not provide any explicit guidance on when to use this tool versus alternatives such as 'ticktick_rename_tag' or 'ticktick_merge_tags'. The usage context is only implied by the action, but no exclusions or alternative recommendations are given.

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 full burden for behavioral disclosure. It clearly states the destructive and irreversible nature of the operation ("This cannot be undone"), which is the most critical behavior. It does not detail permissions or side effects on related data, but for a simple delete this is sufficient.

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 two sentences, front-loads the action, and includes an essential warning. Every word earns its place with no redundancy or filler, making it highly concise and effective.

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 delete operation with no output schema, the description provides the essential context: what it does and its irreversible consequence. It doesn't elaborate on every possible side effect, which is acceptable given the tool's simplicity.

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 already provides descriptions for both parameters (project_id and task_id) with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 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 'Permanently delete a task' uses a specific verb and resource, clearly distinguishing this from sibling tools like complete_task or update_task. The qualifier 'permanently' removes ambiguity about whether it moves to trash or performs a soft delete.

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 usage context: it is the tool for irreversible removal of a task. The warning 'This cannot be undone' contrasts with sibling operations such as complete_task, but it does not explicitly name alternatives or list when-not-to-use scenarios, so a clear but not fully explicit guideline.

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 must convey behavior. It discloses an important behavior: 'All filters are AND-combined'. It does not explicitly state that it performs a read-only operation or describe return format/pagination, but the filter semantics are reasonably transparent.

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, front-loaded with the core purpose, no fluff. Efficiently conveys the key combination behavior.

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 6-parameter filter tool with no annotations or output schema, the description provides basic functionality but lacks usage guidance relative to the many sibling task tools. It doesn't mention scope (e.g., returns all matching tasks) or pagination, though the AND-combination note is helpful. Overall adequate but with gaps.

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 covers all parameters with descriptions, so baseline is 3. The description adds that filters are AND-combined, which explains interaction between parameters. It also groups parameter types (project, priority, date ranges, text search), adding semantic context beyond individual descriptions.

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 function as 'Advanced task filtering' and lists specific criteria (project, priority, date ranges, text search). It distinguishes from sibling list tools by emphasizing combined criteria, though it does not explicitly contrast with ticktick_search_tasks.

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 use when multiple criteria need to be combined ('Combine multiple criteria'), and notes that all filters are AND-combined. However, it does not specify when not to use it or name alternatives, such as ticktick_search_tasks for simple searching.

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. It explicitly discloses that the tool returns 'undone tasks' and only from 'every active project', which are important behavioral constraints. This goes beyond simply restating the name. It stops short of describing return format or pagination, but for a simple read-only list tool, this is adequate and useful.

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 two short sentences: the first states the core functionality with specifics, the second provides a practical use case. Every word earns its place; there is no redundancy or filler.

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?

The tool is low complexity: no parameters, no output schema, and a straightforward data retrieval operation. The description clearly defines what is retrieved (undone tasks) and the scope (active projects), which is sufficient for an agent to select and invoke it correctly without missing critical information. The sibling list further clarifies its role as a broad 'get all' 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 tool has exactly 0 parameters, so the schema is trivially complete. According to guidelines, a baseline of 4 is appropriate. The description neither needs nor adds parameter details, and it correctly focuses on the tool's 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 clearly identifies the verb 'Get', the resource 'all undone tasks', and the scope 'across every active project'. It distinguishes itself from siblings by specifying 'undone' and 'every active project', which differentiates it from filtered variants like overdue or due-date-specific tools, and from completed/trashed task retrievers.

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 second sentence states it is 'Useful for building a full picture of your task list', providing a clear use case. However, it does not explicitly mention when not to use this tool or mention alternatives (e.g., 'use get_tasks_due_today for tasks due soon'). The context is clear but no exclusions are stated, so it earns a 4.

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 must carry the transparency burden. It indicates a read-only list operation by using 'List', and adds the kanban constraint. However, it does not disclose what happens for non-kanban projects (e.g., empty list vs. error) or any return format details.

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 two short sentences with no redundant information. It is front-loaded with the key action and resource, and the second sentence adds a necessary constraint. Zero waste.

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 low complexity (single param, no output schema), the description explains the primary purpose and applicability. However, without an output schema it does not describe what a column object looks like or the shape of the response, leaving some contextual gaps.

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 already describes project_id as 'The project ID' with 100% coverage. The description adds no extra meaning beyond what the schema provides, so the baseline of 3 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 states the action (List), the resource (all Kanban columns for a project), and the scope (per project). It also distinguishes itself from siblings by noting it is only for kanban view mode, which is a specific constraint.

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 a clear usage condition by stating 'Only applicable to projects using kanban view mode.' It implies when to use this tool, though it does not name alternative tools for non-kanban projects or explicitly exclude other cases.

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 burden of behavioral disclosure. It indicates a read operation and the date range filter, but omits details like default limit (visible in schema), ordering, or response format, leaving slight ambiguity about the full 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 two sentences, front-loaded with the core function and a brief usage tip. Every word contributes value, with no redundant 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 simple read tool, the description provides the essential purpose, a use case, and mentions filtering. It lacks output format details, but since there is no output schema, this is not a major gap. The description is complete enough for tool selection and invocation.

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 fully documents all three parameters with descriptions and examples, so the description need not repeat them. It adds context by linking date range to filtering completed tasks, but does not elaborate on parameter semantics beyond that, which is adequate given 100% schema coverage.

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 it retrieves tasks that are completed, using the specific verb 'Get' and resource 'completed tasks'. This distinguishes it from sibling tools like get_tasks_due_today or get_all_tasks, which serve different retrieval purposes.

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 a clear use case ('reviewing what you've accomplished') and mentions optional date range filtering, helping an agent understand when to use this tool. It does not explicitly contrast with alternatives, but the context is sufficient.

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 present, so the description carries the full burden. It discloses the filtering criteria (priority 5, overdue, due today) but does not describe return format, sorting, or any side effects. Adequate for a simple read tool but not rich in behavioral context.

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 one concise sentence, front-loaded with the action and resource, with clear criteria and a rationale (GTD). No waste.

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?

The tool is simple with no params, no output schema, and no annotations. The description fully captures the filtering logic, but does not clarify the relationship to overlapping sibling tools (e.g., combining due today, overdue, and priority filters), which 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 tool has zero parameters, so the description holds no burden for explaining parameter meaning. Baseline of 4 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?

The description clearly defines the tool's purpose: retrieving tasks requiring immediate engagement, explicitly enumerating criteria (priority 5, overdue, due today). This distinguishes it from sibling tools like get_tasks_due_today or get_overdue_tasks by combining them.

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 does not explicitly state when to use this tool instead of alternatives like get_tasks_due_today or get_overdue_tasks. It implies usage through the GTD context and criteria, but lacks explicit 'when to use' or exclusion 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?

No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states the basic function without mentioning return format, date range inclusivity, data granularity, or any auth requirements. This is a significant gap for a tool with no annotation support.

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?

A single sentence of 14 words immediately states the tool's purpose. No filler or repeated information, 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?

The tool is simple (2 params, no output schema), but without annotations or an output schema, the description should clarify what the distribution looks like (e.g., counts vs. percentages) or any behavioral details. It doesn't, leaving the agent to guess the output 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?

The schema already documents both parameters (from/to as start/end dates with format YYYY-MM-DD), so coverage is 100%. The description adds the concept of a 'date range' but no additional semantic detail beyond the schema definitions.

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 uses the verb 'Get' with a specific resource: focus time distributed across tags/categories. This clearly distinguishes it from sibling tools like get_focus_heatmap (heatmap) or get_tags (list tags), and the date range scope is explicit.

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 explicit guidance on when to use this tool versus siblings like get_focus_heatmap or get_productivity_stats. The intended use case is only implied by the description itself; there are no exclusions or alternative tool names mentioned.

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 of disclosure. It adds some useful behavioral context by stating that the heatmap shows daily focus totals including pomodoro and stopwatch time, but it does not disclose the response format, edge cases (e.g., empty days), or explicitly confirm read-only 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 two concise sentences, front-loaded with the main purpose and a secondary detail about what the heatmap includes. Every word serves a clear function, with no redundancy.

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 (two parameters, no output schema), the description covers the core behavior but leaves ambiguity about the exact return structure (e.g., is it an image or data array?) and lacks any limitations or usage caveats. It is adequate but not fully complete.

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 already fully describes both parameters (from/to) with date format examples, achieving 100% coverage. The description merely reiterates the date-range concept without adding new semantic details such as inclusive/exclusive bounds or timezone handling.

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 uses a specific verb ('Get') and identifies the exact resource ('a heatmap of your focus/pomodoro time') with a date range scope. It clearly distinguishes this tool from siblings like productivity stats or task lists by focusing on the heatmap representation and daily focus totals.

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 no guidance on when to use this tool versus alternative analytics tools such as ticktick_get_focus_distribution or ticktick_get_productivity_stats. It only states what the tool does without offering context on scenarios that favor this 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?

No annotations are provided, and the description uses 'Get' to imply a read-only operation, which is useful. However, it does not disclose details about return format, pagination, limits, or whether the operation is safe. It adds the date-filter context but remains minimal.

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?

A single, concise sentence fully conveys the tool's purpose. It is front-loaded with the action and leaves no filler, making it easy to parse.

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?

The tool is simple, and the schema documents both parameters fully. However, without an output schema or annotations, the description does not explain what a response contains (e.g., fields like date, habit_id, status) or any edge cases. It is adequate but minimal for complete agent understanding.

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%, with both 'habit_ids' and 'after_date' already described. The description adds slight reinforcement ('one or more habits' and 'from a specific date onward') but does not provide additional semantics beyond the schema. Baseline 3 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 states the action ('Get'), the resource ('check-in records'), and the scope ('for one or more habits from a specific date onward'). It distinguishes itself from sibling tools like ticktick_get_habits (which lists habits) and ticktick_checkin_habit (which records a check-in).

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 its use case: retrieving historical check-in data for habits. However, it does not explicitly mention when to use this tool versus alternatives (e.g., get_habits or checkin_habit) or when not to use it. Context is clear but lacks explicit 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?

No annotations are provided, so the description carries the transparency burden. It clearly states this is a read-only list operation and specifies the included fields (name, frequency, goal, streak info), but does not disclose potential caveats such as pagination, ordering, or whether only active habits are 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?

Single sentence, front-loaded with the verb and resource, no filler words. Every part 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 parameterless list tool, the description covers purpose, scope, and return fields. Although there is no output schema, it gives sufficient context for an agent to invoke correctly. It does not reference sibling tools, but that is not required for this simple GET-style operation.

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 zero parameters, so there are no parameter semantics to clarify. The description adds value by listing the returned fields (name, frequency, goal, streak info), surpassing the empty schema baseline.

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 uses specific verb 'List' with resource 'habits' and scope 'all in your TickTick account'. It clearly distinguishes from sibling tools like get_habit_sections or create_habit by stating it lists all habits and the included data fields.

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 use when you need an overview of all habits and their tracking info, but does not explicitly mention when not to use it or alternatives such as ticktick_get_habit_sections or ticktick_get_habit_checkins. No exclusions or situational context is provided.

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 indicates a read-only 'get' operation but does not disclose any additional behavioral traits such as whether only sections with habits are returned, ordering, or potential side effects. The description is not misleading but lacks explicit transparency beyond the basic action.

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 a single, front-loaded sentence that immediately states the action and resource, followed by a clarifying parenthetical and elaboration. Every word adds value with no redundancy or filler.

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 (no parameters, no output schema, no annotations), the description fully covers what the tool does and what it returns. It is exhaustive for a zero-parameter getter, specifying both the sections and their habit membership, satisfying the contextual needs of an AI agent.

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 zero parameters, so there is no parametric complexity to explain. The baseline for 0 params is 4, and the description does not need to compensate for any schema gaps since the schema is empty and completely covered by the absence of parameters.

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 uses a specific verb 'Get' with a clear resource 'habit sections' and specifies the additional grouping detail 'and which habits belong to each.' This clearly distinguishes it from sibling tool ticktick_get_habits, which likely returns a flat list of habits rather than grouped sections.

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 its use when you need habit sections with associated habits, but it does not explicitly state when to prefer this over other habit-related tools like get_habits or checkin_habit. No exclusions or alternative guidance is provided, leaving the usage context 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 burden. It explicitly discloses the selection logic (priority 3 OR due tomorrow), which is key behavioral insight. However, it does not mention ordering, whether completed tasks are excluded, or any other hidden behavior, leaving some gaps.

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 two short sentences. The first states the primary purpose immediately, and the second adds specifics and GTD context. Every word 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 zero-parameter read-only tool, the description covers the selection criteria and the GTD rationale. It is slightly incomplete in not stating ordering or treatment of completed tasks, but the simplicity and sibling context make it adequate.

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 zero parameters, so the baseline is 4. The description adds conceptual meaning by explaining what the returned tasks represent, which is sufficient given no parameters exist.

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 'Get', the resource 'tasks', and specific selection criteria 'medium priority (3) or due tomorrow'. This distinguishes it from siblings like get_tasks_due_tomorrow (only due tomorrow) and get_tasks_by_priority (only priority).

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 GTD methodology reference implies the primary use case for next-action lists, but it does not explicitly state when not to use it or name alternatives. The criteria themselves separate it from other task-retrieval tools, but direct usage guidance is lacking.

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 accurately states the selection behavior (tasks past due date) but omits operational details like whether completed tasks are included, timezone handling, ordering, or pagination. This is adequate but not rich.

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, front-loaded with the core function and second sentence adding actionable context. No filler or repetition.

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 low complexity (0 params, no output schema, no annotations), the description sufficiently conveys what the tool does and when it is appropriate. Minor gaps like return format or task-status inclusion exist, but they do not hinder tool selection or invocation.

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 zero parameters, the schema is fully covered and no parameter semantics are needed. The description adds no parameter details, but none are required; the baseline of 4 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?

The description uses a specific verb ('Get') and resource ('all tasks that are past their due date'), clearly distinguishing this from siblings like get_tasks_due_today or get_all_tasks. The phrasing 'These need immediate attention' reinforces the operational purpose without ambiguity.

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: use this when you need tasks that are overdue and require immediate attention. It does not explicitly name alternative tools or state exclusions, but the 'past due' criterion unambiguously separates it from other task-time-based 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, the description carries the full burden. It discloses the nature of the operation ('Get') and the type of data, but does not mention any side effects, return format, or potential limitations. For a simple read-only tool with no parameters, this is adequate but lacks depth.

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 a single concise sentence that front-loads the purpose and lists the metrics without wasted words. It is perfectly sized for the tool's simplicity.

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 no output schema, the description provides enough context by enumerating the statistics returned. It could be slightly more explicit about the output structure, but for a simple getter this is sufficiently complete.

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 zero parameters, so the baseline is 4. The description adds meaning by describing the output fields, which is useful for understanding what the tool returns, even though parameter semantics are not applicable.

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 'get' and the resource 'overall productivity statistics', then enumerates the specific metrics (tasks completed, tasks created, pomodoro count, habit check-ins, productivity score). This distinguishes it from sibling tools like focus heatmap or task listing functions.

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 explicit guidance on when to use this tool versus alternatives. However, the description makes it obvious that it's for overall productivity statistics, so usage is implied. Missing explicit alternatives or exclusions, but not misleading.

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 discloses that the tool returns project metadata and the kinds of fields included, which is useful. However, it does not state error behavior (e.g., invalid ID), authentication requirements, or rate limits. For a read operation, this is minimally viable but lacks depth beyond the obvious 'get' semantics.

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 two sentences, front-loaded with the verb and resource, and contains no redundant information. Every word contributes to explaining purpose or return value.

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?

The tool is simple (one parameter, no output schema). The description explains the purpose and partially lists the return fields, using 'including' to indicate a non-exhaustive list. While it does not enumerate every possible metadata field or error conditions, it is sufficient for an agent to understand the tool's scope. Given the lack of an output schema, the description does a decent job of setting expectations.

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%, with the 'project_id' parameter described as 'The project ID'. The description adds no new semantic detail about the parameter, though it reinforces that the ID identifies the project. Since the schema already fully documents the parameter, the baseline of 3 is appropriate; no compensation is needed.

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 action ('Get details') and the resource ('specific project') with an explicit identifier ('by its ID'). It also lists the return content (name, color, view mode, permissions), distinguishing it from sibling tools like get_projects which retrieves multiple projects.

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 usage for retrieving a single project when you have the project ID, which provides clear context. However, it does not explicitly mention alternatives or exclusions, such as using get_projects for a list of projects. The clarity of 'specific project by ID' gives enough guidance for an agent to select this tool over similar ones.

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 burden. It discloses that the tool returns undone tasks and Kanban columns, giving behavioral insight beyond a simple project fetch. It does not mention mutation or side effects, but the verb 'Get' clearly indicates a read 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?

Two short sentences with no redundancy. The main verb and purpose appear in the first sentence, making it immediate and clear.

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 without an output schema, the description sufficiently conveys the scope of returned data. It could explicitly mention the return structure, but this is a minor gap given the simplicity of 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 schema already describes project_id as 'The project ID' with 100% coverage. The description adds no further parameter semantics, so it aligns with the baseline score of 3 for high schema coverage.

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 retrieves a project, its undone tasks, and Kanban columns. This distinguishes it from the sibling ticktick_get_project, which likely only fetches project metadata.

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 context by noting it is useful for seeing the full state of a project, implying it is the comprehensive choice. However, it does not explicitly name alternatives or provide exclusion criteria.

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 full burden for behavioral disclosure. It accurately states the action (listing all folders) and adds a clarifying note with '(groups)'. However, it does not explicitly state that this is a read-only operation or describe the return format, which is a minor gap given the simplicity of the 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?

The description is a single, front-loaded sentence with no wasted words. It states the action, the resource, and a brief clarifying parenthetical, achieving maximum informational density in minimal space.

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, parameterless list operation, the description is fully complete. It clearly indicates what the tool does and requires no further elaboration. The lack of an output schema is acceptable here because the return value (a list of folders) is self-evident from the tool's purpose.

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 zero parameters, so the schema trivially covers 100% of them. The description correctly implies no arguments are needed. No additional parameter explanation is required or possible, meeting the baseline expectation for a parameterless tool.

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 uses the specific verb 'List' and clearly names the resource 'project folders', adding the explanatory '(groups)' and clarifying their purpose in organizing projects. This fully distinguishes it from sibling tools like ticktick_get_projects (which lists projects, not folders) and ticktick_create_project_folder (which creates folders).

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 by stating these folders are 'used to organize projects', implying this tool is for retrieving the grouping structure. It does not explicitly mention alternatives or exclusions, but the purpose is so clear that an agent would naturally select it when folder-level data is needed, especially alongside create/delete/move folder siblings.

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 burden. It discloses the return fields and scope ('all projects'), which is helpful, but it doesn't mention potential pagination, auth, or 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 two concise sentences, front-loaded with the main action, and every word adds value. No fluff or redundancy.

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 zero-parameter list tool with no output schema, the description fully covers what it does and what it returns. It is complete for the tool's complexity.

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 zero parameters, and the schema is empty with 100% coverage. The description correctly doesn't add parameter details since none exist, matching the baseline for zero-param tools.

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 'List all projects' with a specific verb and resource, and the return fields (IDs, names, colors, view modes, closed status) distinguish it from sibling tools like ticktick_get_project.

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 clearly implies the tool is for fetching all projects, which gives context for when to use it, but it doesn't explicitly mention alternatives or when not to use it, so a small deduction is warranted.

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. 'List' implies a read-only operation, and the mention of return fields gives some behavioral detail. However, it does not explicitly state that it does not modify data, nor does it describe pagination, rate limits, or error behavior. Since it is a simple listing operation, this is acceptable but not thorough.

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 two sentences, front-loaded with the action ('List all tags'), and every word adds value by specifying the output contents. There is no redundancy or irrelevant detail.

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 zero-parameter tool with no output schema, the description sufficiently covers the return content (names, colors, sort order). However, it could be more complete by explicitly stating the response format (e.g., an array of tag objects) or any limitations, but given the simplicity of the tool, the current level is adequate.

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 zero parameters, and the schema provides 100% coverage (empty object). Therefore, the description does not need to add parameter context. Baseline for zero parameters is 4.

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?

Purpose is fully clear: 'List all tags' uses a specific verb plus resource, and it explicitly states the returned data (tag names, colors, sort order). It is distinct from sibling tools like create_tag, rename_tag, and delete_tag, and also from project/task listing 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 description makes the use case obvious: when you need to retrieve all tags in the account. While it doesn't explicitly state when not to use it or name alternatives, the context of sibling tools (e.g., get_projects, get_tasks) provides clear separation, so the intended usage is unambiguous.

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 must convey side effects. It clearly indicates a read operation ('Retrieve') and discloses the return content ('full task details including subtasks, dates, priority, and content'). However, it does not document error behavior, permission requirements, or rate limits, leaving some gaps.

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 one to two sentences long, front-loaded with the action, and contains no extraneous information. Every word 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?

With no output schema, the description adequately explains the return value ('full task details including subtasks, dates, priority, and content'). It also identifies both required parameters. This is sufficient for a simple retrieval 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 already provides 100% descriptions for both task_id and project_id. The description repeats this by saying 'by its project ID and task ID' but adds no additional semantics, examples, or constraints. Baseline of 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?

The description uses the specific verb 'Retrieve' and identifies the resource as 'a specific task' identified by project ID and task ID, which clearly distinguishes it from sibling tools like get_all_tasks or search_tasks.

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 usage when you have both project ID and task ID and need full task details, but it does not explicitly mention when not to use it or name alternatives. Therefore scored as implied 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 carries the full burden of behavioral disclosure. It describes a read operation ('Get') but does not explicitly state that it is read-only, nor does it mention pagination, ordering, or any side effects. The description adds minimal behavioral context beyond the name.

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 two short sentences, front-loaded with the action, and includes the necessary priority value mapping. No redundant information is present.

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 single-parameter read tool, the description covers the essential information: what it returns (tasks), the filter (priority), and the value meanings. However, the absence of an output schema or behavioral notes (e.g., read-only confirmation) leaves minor gaps, but the tool's simplicity mitigates this.

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 fully documents the only parameter (`priority`) with the same text as the description, so the description adds no new semantic information. The schema coverage is 100%, meeting the baseline for this dimension.

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 identifies the tool's action ('Get all tasks') and the specific filtering criterion ('by a specific priority level'), distinguishing it from sibling tools like get_tasks_due_today or get_all_tasks. The priority values are explicitly defined, providing unambiguous 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 states the function but does not provide guidance on when to choose it over other task-listing tools (e.g., get_all_tasks, filter_tasks). There is no mention of alternative tools or exclusions, so the usage context is only implied.

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 of behavioral disclosure. It only states the basic read operation and does not clarify whether the date range includes today, whether overdue tasks are excluded, whether completed tasks are included, or how results are ordered. The meaning of 'due' is left ambiguous.

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 a single, direct sentence that is front-loaded and free of fluff. It is appropriately sized for a simple tool, though some behavioral details could have been added without sacrificing conciseness.

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 simplicity of the tool (one parameter, no output schema), the description is minimally adequate. However, the presence of many sibling tools with similar date-based filters means the description lacks enough context to help the agent decide when this tool is the right choice. It does not mention return format, filtering semantics, or relationship to other tools.

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 for the single parameter 'days' is 100%, with the schema already providing a clear example. The description only reiterates the concept and adds no additional semantics or format details beyond 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?

The description 'Get all tasks due within the next N days' clearly identifies the verb (get), resource (tasks), and scope (due within N days). The customizable N distinguishes this from sibling tools like 'due today' or 'due this week'.

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 usage guidance is provided. The description does not explain when to use this tool instead of alternatives such as ticktick_get_tasks_due_today, ticktick_get_tasks_due_this_week, or ticktick_get_overdue_tasks. There is no mention of exclusions or prerequisites.

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. It discloses the 7-day window, which is useful behavioral detail, but omits edge cases like whether overdue tasks are excluded, whether completed tasks are included, and timezone handling. The description is minimal and does not address these potential ambiguities.

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 a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded and contains no fluff, earning a high 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 zero-parameter read tool with no output schema, the description is largely complete: it specifies the exact set of tasks returned. Minor gaps like sorting or project scope exist, but the low complexity and clear sibling set make the description sufficient.

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 takes zero parameters, and schema coverage is 100% since there are no parameters to document. Baseline for 0 params is 4, and the description adds no unnecessary parameter details, 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 'Get all tasks due within the next 7 days' clearly states the specific verb (get), resource (tasks), and scope (due within 7 days), effectively distinguishing it from sibling tools like ticktick_get_tasks_due_today, ticktick_get_tasks_due_tomorrow, and ticktick_get_overdue_tasks.

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 usage when needing tasks due this week, but does not explicitly mention when to prefer this over alternatives such as ticktick_get_tasks_due_in_days or ticktick_get_tasks_due_today. No exclusions or alternative guidance is provided, though the time range gives clear context.

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 full responsibility for behavioral disclosure. It only restates the tool's function and offers a generic motivational phrase, without noting potential nuances like timezone handling, project scope, or that it returns only tasks from all lists. This is insufficient for a 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?

The description is two short sentences and front-loads the functional statement. The second sentence adds a slight usage context but is somewhat generic; overall it is efficient and without unnecessary verbosity.

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 (zero parameters, no output schema, read-only intent), the description adequately covers the essential context. It does not explain return format, but for a 'get tasks' tool this is largely self-evident. It is not missing critical information for an agent to select and 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?

The tool has zero parameters and the schema is fully covered (empty properties). Per the baseline for 0 params, the description does not need to add parameter details, and it does not attempt to, 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 states the tool retrieves all tasks due today, using a specific verb and resource with a clear temporal scope. It distinguishes itself from sibling tools like ticktick_get_tasks_due_tomorrow and ticktick_get_overdue_tasks.

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 second sentence implies usage for immediate focus ('right now'), but it does not explicitly mention when not to use this tool or name alternatives. The purpose is clear enough for an agent to infer, but explicit guidance is missing.

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 full responsibility for behavioral disclosure. It does not specify whether completed tasks are included, what constitutes 'due tomorrow' (e.g., timezone or tasks without specific times), or the format of the returned data. This is minimal for even a simple read 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?

The description is a single sentence with no wasted words, achieving high conciseness and front-loading 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's simplicity (zero parameters, no output schema), the description is adequate but leaves gaps. It doesn't explain the exact meaning of 'due tomorrow' (e.g., timezone handling, completed tasks) or why to pick this over get_tasks_due_in_days. For a basic list tool, it's usable but not fully complete.

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 zero parameters, so the baseline is 4. The description adds no parameter details but also doesn't need to, as the schema is empty.

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 "Get all tasks that are due tomorrow" uses a specific verb (Get) and resource (tasks), with an explicit scope (due tomorrow). This clearly distinguishes it from sibling tools like get_tasks_due_today and get_tasks_due_this_week.

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 its use for retrieving tasks due tomorrow but does not explicitly state when to use it versus alternatives such as get_tasks_due_in_days or get_overdue_tasks. No exclusions or alternative recommendations are provided.

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. It accurately states that the tool retrieves deleted/trashed tasks and implies recoverability, which is the essential behavior. However, it does not disclose return format, pagination behavior, or any edge cases, leaving some transparency gaps.

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 two concise sentences that front-load the core purpose and follow with a relevant use case. There is no fluff or redundant information, making it highly efficient.

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 read-only tool with two fully documented parameters and no output schema, the description sufficiently covers the purpose and use case. It could mention that it returns a list of trashed tasks with standard fields, but the current level is adequate given the low complexity.

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 complete descriptions for both parameters (limit and start), including defaults and pagination semantics. The description adds no extra parameter information beyond the schema, so the baseline of 3 is appropriate given 100% schema coverage.

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 identifies the tool's function: retrieving deleted/trashed tasks. It uses a specific verb (Get) and resource (tasks that have been deleted/trashed), and uniquely distinguishes itself from sibling tools like ticktick_get_task or ticktick_get_all_tasks by targeting trashed tasks specifically.

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 a clear use case ('useful for recovering accidentally deleted items') but does not explicitly state when not to use it or mention alternative tools. This is strong contextual guidance but lacks the explicit exclusions/alternatives that would earn 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?

No annotations are provided, so the description carries the full burden. It indicates a read operation via 'Get', but does not disclose any behavioral traits like response format, authentication requirements, or rate limits. For a simple profile retrieval this may be adequate, but transparency is minimal.

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 a single, concise sentence that front-loads the action and resource, and lists key return fields. It is well-structured with no redundancy.

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 no output schema, the description lists the expected return fields, providing sufficient context for an agent to decide when to invoke it. It lacks usage guidance, but for a simple profile getter, the information is reasonably complete.

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 zero parameters, so the baseline is 4. The description correctly implies no inputs are needed, and the schema confirms this. No additional parameter information is needed.

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 retrieves the user profile, listing specific fields (name, email, timezone, inbox ID, subscription status). It uses a specific verb 'Get' and resource 'user profile', distinguishing it from sibling tools like get_user_settings.

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 no guidance on when to use this tool versus alternatives, such as get_user_settings. It gives no context on use cases or exclusions, leaving the agent to infer.

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 burden of behavioral disclosure. While 'Get' implies a read-only operation, the description does not explicitly state that it has no side effects, requires no special permissions, or describe any response behavior beyond the settings retrieval. It provides the core action but lacks additional context.

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 a single concise sentence that front-loads the action 'Get' and includes illustrative examples. Every word earns its place with no redundancy.

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 zero-parameter getter with no output schema, the description sufficiently conveys what the tool does and implies the return value (account settings and preferences). It is complete enough for an agent to understand the tool's function, though it does not detail the response 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?

The tool has zero parameters, so the baseline is 4. The description confirms that no inputs are needed by simply stating it retrieves settings. No parameter explanation is required beyond that.

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 'Get' and the specific resource 'account settings and preferences' with concrete examples (timezone, start of week). This distinguishes it from sibling tools like get_user_profile, which would handle profile data rather than settings.

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 is provided on when to use this tool versus alternatives such as get_user_profile or other getters. There are no explicit conditions, exclusions, or alternative tool names mentioned.

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?

The description discloses a key behavioral outcome: all tasks with the source tag will be re-tagged to the destination tag, which goes beyond the tool name. However, it does not explicitly mention whether the source tag object is deleted or if the operation is reversible, leaving some gaps.

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 two sentences with no fluff, front-loading the core action and then explaining the consequence. Every word 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 tool with no output schema, the description effectively conveys the operation and its main effect. It lacks edge-case details like error handling or same source/destination scenarios, but overall it is sufficiently complete.

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 fully describes both parameters (to_tag kept, from_tag removed), and the tool description reinforces the relationship. Since schema coverage is 100%, the description adds minimal new parameter meaning but clarifies the effect on tasks.

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 action (merge one tag into another) and the key consequence (all tasks with source tag re-tagged to destination). This distinguishes it from sibling tools like rename_tag or delete_tag.

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 explains what the tool does but does not explicitly state when to use it versus alternatives like rename_tag or delete_tag. The usage is implied by the merge operation, but no exclusions or alternative recommendations are provided.

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?

There are no annotations, so the description carries the full burden, but it does not add behavioral context beyond the schema. The special sentinel values for removal are already described in the input schema, and the description merely repeats them. It lacks disclosure of side effects, error behavior, or any other non-obvious traits.

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 three sentences and efficiently front-loads the core action, then explains the two usage modes, and ends with the sibling reference. No redundant or verbose phrasing; every sentence contributes.

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 2-parameter tool with no output schema, the description covers the essential purpose, usage modes, and how to find prerequisite IDs. It is complete enough for an agent to select and invoke the tool correctly, though it omits return value details which may be assumed.

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% for both parameters, so the baseline is 3. The description does reiterate the folder_id semantics ('Pass a folder_id... pass an empty string...') but this is exactly what the schema already states, adding no new meaning. It does not elaborate on project_id beyond its schema description.

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 moves a project/list into a folder or removes it from a folder, using specific verbs and resources. It distinguishes itself from task-moving tools by explicitly mentioning 'project folder' and the removal variant. This is unambiguous and differentiates from siblings like ticktick_move_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?

The description provides explicit guidance on when to use the tool (to move a project into or out of a folder) and how to use it (pass folder_id or sentinel values). It directly references a sibling tool (ticktick_get_project_folders) for finding folder IDs, which is a clear alternative and prerequisite. This is strong usage direction.

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 for behavioral disclosure. It states that the task is moved, but does not disclose whether this is destructive (removes from old project), whether it returns anything, or what happens if the old project ID is invalid. The verb 'move' implies a transfer, but no explicit behavioral details are provided.

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 a single, concise sentence with no unnecessary words. It front-loads the core action and is immediately understandable. It is appropriately sized for the simplicity of the operation.

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?

Despite the low complexity (3 parameters, no output schema, no nested objects), the description is minimal. It does not mention the return value, side effects, or any prerequisites. Since there are no annotations, the description should provide more context about what happens during the move, but it does not. This leaves the agent under-informed.

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%, with each parameter having a clear description (Task ID to move, Destination project ID, Current project ID). The tool description does not add meaning beyond the schema, but it also does not need to, as the schema already fully documents the parameters. Baseline 3 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 states the action: 'Move a task from one project to another.' It uses a specific verb (move), names the resource (task), and describes the scope (between projects). This distinguishes it from sibling tools like update_task or move_task_to_column, which have different purposes.

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 guidance on when to use this tool vs alternatives. The description only states what it does, not when to prefer it over update_task or set_task_parent. No exclusions or alternative tools are mentioned, leaving the agent without decision-making support.

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. It adds meaningful context by stating the task keeps all other fields and the move is within the same project. However, it does not disclose return values, error handling, or permission requirements, which are important 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?

The description is two concise sentences, front-loaded with the core action, followed by a practical prerequisite and a behavioral guarantee. Every sentence contributes value with no redundancy.

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 2-parameter move tool with no output schema and no annotations, the description covers the core action, the required prerequisite for column IDs, and a key behavioral guarantee. It lacks return value and error details, but the simplicity of the operation makes this adequate rather than insufficient.

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%, with both parameters already described in the input schema. The description reinforces the column_id source from ticktick_get_columns but does not add new parameter-specific semantics beyond the schema, so the baseline of 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?

The description uses a specific verb 'Move' and clearly identifies the resource (task) and target (Kanban column within its project). It distinguishes from sibling tools like ticktick_move_task by specifying the column context, making the purpose 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 explicitly instructs to use ticktick_get_columns to find the destination column ID, providing a concrete prerequisite. It implies the tool is for moving between Kanban columns but does not explicitly mention alternative tools or when not to use it, so it stops short of 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?

No annotations are provided, so the description carries the burden of disclosing side effects. It explicitly states 'All tasks with this tag will be updated,' which is a key behavioral trait beyond the mere rename. It does not mention failure modes or irreversibility, but the disclosed cascading update adds meaningful 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 two concise sentences, front-loaded with the primary action. Every sentence adds value—the second sentence clarifies the side effect. No redundant or filler content.

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?

The tool is simple (two string parameters, no output schema), and the description covers the core operation and its effect. It avoids over-explaining return values since none are expected. Minor omissions such as error handling or prerequisite checks, but acceptable for the tool's simplicity.

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?

Input schema covers both parameters (old_name and new_name) with descriptions, so schema coverage is 100%. The description adds no additional parameter-level meaning beyond what the schema already provides, justifying the baseline score of 3.

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 uses a specific verb+resource: 'Rename an existing tag.' It clearly distinguishes this from sibling operations like create, delete, merge, and get tags by stating the action and its scope. The added effect 'All tasks with this tag will be updated' 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 implies when to use the tool (when a tag's name needs changing) but does not explicitly contrast it with alternatives like merge_tags or create_tag. It gives no when-not-to-use guidance or edge cases, so usage context is only 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 provided, the description carries the full burden of behavioral disclosure. It adds useful context by specifying that it matches against title, content, and subtask titles across all active projects, but it doesn't explicitly state that it's read-only or what the return format is. The lack of output schema makes this a minor gap.

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 two concise sentences that are front-loaded with the verb. Every word contributes meaning, with no redundancy or filler, making it highly efficient.

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 one-parameter search tool, the description covers the essential behavior and scope. Although there is no output schema to explain return values, the purpose is clear enough that an agent can infer the tool returns matching tasks. It could be slightly more complete by explicitly mentioning output, but the current description is adequate.

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 describes the query parameter only as 'Search text to match against task titles and content', but the description adds that it also matches subtask titles and operates across all active projects. This goes beyond the schema and provides additional meaning.

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 'Search for tasks by text', clearly identifying the verb and target. It further specifies that it matches title, content, and subtask titles across all active projects, making its scope distinct from sibling tools like get_all_tasks.

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 this tool: when searching tasks by text across all active projects. However, it does not mention alternatives or situations where it should not be used, such as when filtering by structured criteria (for which filter_tasks might be more appropriate).

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 must carry the full behavioral burden. It discloses the key edge case (empty parent_id removes the relationship), but says nothing about permissions, side effects, or response format. Adequate but not rich.

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, front-loaded with the core action, and every clause earns its place. No fluff or redundancy.

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 setter operation with full parameter descriptions, the description covers the main behavior and the removal edge case. It omits return value details, but with no output schema and a straightforward action, this is not a significant 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?

Schema descriptions cover all three parameters at 100%, including the empty-string removal behavior for parent_id. The description adds no new information beyond what the schema already provides, so a baseline 3 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 states 'Make a task a subtask of another task by setting its parent', which is a specific verb+resource. It also distinguishes itself by explicitly covering the remove-parent case with an empty parent_id, separating it from generic update/move 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 description implies when to use the tool (to set or remove a parent relationship), but does not explicitly mention alternatives like ticktick_update_task or provide any when-not-to-use guidance. Usage is clear but not fully elaborated.

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 full burden. It lists mutable properties but does not disclose whether updates are partial (only provided fields) or any side effects, permissions, or response behavior. For a mutation tool, this is a significant gap.

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 two concise sentences, front-loaded with the action, and contains no filler. Every word is useful.

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 no output schema, the description should mention partial update behavior or return values. The schema covers parameters, but behavioral context is missing, leaving the tool incomplete for safe agent use.

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%, with each parameter clearly described. The description's field list (name, color, view mode, kind) adds no additional meaning beyond the schema, so baseline 3 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 states 'Update an existing project's properties' with a specific verb and resource, and enumerates the updatable fields (name, color, view mode, kind), distinguishing it from create/delete/get 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?

The phrase 'existing project' implies modification rather than creation, providing context. No explicit alternatives are named, but the usage context is clear given the tool's name and the sibling list.

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 burden. It adds the key behavioral trait that only provided fields are changed, indicating a partial update. However, it doesn't disclose return value, permissions, or failure modes.

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 three short sentences, front-loaded with the core action, then requirements, then behavior. There is no wasted text.

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?

Despite having 14 parameters and no output schema or annotations, the description is minimal. It doesn't explain return values, use cases, or contrast with sibling update tools, leaving the agent with insufficient context for a complex 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 full descriptions for all 14 parameters (100% coverage). The description adds value by clarifying that only the fields you provide will be changed, which helps agents understand that parameters are optional and updates are partial.

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 'Update an existing task' with a specific verb and resource. It also specifies required parameters (task_id and project_id). However, it doesn't explicitly distinguish this tool from sibling update tools like complete_task or move_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?

The description provides prerequisites (both task_id and project_id are required) and the partial update behavior, which implies when to use it. But it doesn't provide explicit guidance on when to use this instead of alternatives like complete_task or move_task.

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