TickTick MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation3/5
The tools are generally well-differentiated by resource type (tasks, projects, habits, tags, focus) and action, but there is some overlap in functionality. For example, 'ticktick_get_task' and 'ticktick_list_tasks' serve distinct purposes, but 'ticktick_get_completed_tasks' and 'ticktick_get_today_habits' might be confused with broader listing tools. Descriptions help clarify, but the high tool count increases potential for misselection.
Naming Consistency5/5
All tool names follow a consistent 'ticktick_verb_noun' pattern with snake_case throughout. The verbs are clear and appropriate (e.g., create, get, update, delete, list), and nouns consistently represent TickTick entities like tasks, projects, habits, tags, and focus. This uniformity makes the tool set predictable and easy to navigate.
Tool Count2/5
With 55 tools, the count is excessive for a task management server, even considering TickTick's broad feature set. This many tools can overwhelm agents, leading to confusion and inefficiency. A more streamlined set, perhaps grouping related operations or reducing redundancy, would be more appropriate for the domain.
Completeness5/5
The tool set provides comprehensive coverage of TickTick's domain, including full CRUD operations for tasks, projects, habits, tags, and folders, plus advanced features like focus tracking, analytics, and OAuth authentication. There are no obvious gaps; agents can perform all core workflows from task management to productivity analysis without dead ends.
Average 3.7/5 across 55 of 55 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation), idempotentHint=true, and destructiveHint=false. The description adds context about v2 API authentication, which is valuable beyond annotations. However, it doesn't detail behavioral traits like what happens with partial updates, error conditions, or response format, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by authentication details. Both sentences are relevant, with no wasted words, making it efficient. However, the lack of structure (e.g., bullet points for parameters) slightly limits readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with multiple optional fields), annotations cover safety (non-destructive, idempotent), and an output schema exists, reducing the need for return value details. However, the description lacks parameter explanations and usage context, making it incomplete for optimal agent understanding despite structured data support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with 1 parameter (a nested object 'params' containing multiple fields like 'habit_id', 'name', etc.). The description mentions 'properties' generically but doesn't explain specific parameters (e.g., 'habit_id' is required, others are optional with null defaults). This fails to compensate for the lack of schema descriptions, leaving semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing habit's properties'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_create_habit' or 'ticktick_delete_habit', which would require mentioning creation or deletion specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it mentions authentication requirements but offers no explicit when-to-use advice, such as distinguishing from 'ticktick_create_habit' for new habits or 'ticktick_get_habit' for retrieval. Without this, the agent lacks clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description adds that it 'marks a task as complete', which aligns with these annotations by implying a state change without destruction. However, it doesn't provide additional behavioral context like side effects, permissions needed, or rate limits, relying on annotations for core traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence ('Mark a task as complete.'), front-loaded and waste-free. Every word contributes to the core purpose without unnecessary elaboration, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with idempotency), annotations cover key behavioral traits, and an output schema exists (reducing need to describe returns). However, the description lacks details on usage context, parameter specifics, and sibling differentiation, making it minimally complete but with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description implies a single parameter (task to mark complete) without detailing it. Since there's only one parameter (a nested object with task_id and project_id), the description's simplicity is adequate, but it doesn't explain the parameter structure or requirements beyond the basic action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark a task as complete' clearly states the action (mark as complete) and resource (task), but it's vague about scope and doesn't distinguish from sibling tools like 'ticktick_uncomplete_task' or 'ticktick_delete_task'. It provides basic purpose but lacks specificity about what 'complete' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_uncomplete_task' (for reversing completion) or 'ticktick_delete_task' (for removal). There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering basic safety and idempotency. The description adds context about folders organizing projects, which is useful but doesn't disclose additional behavioral traits like permission requirements, rate limits, or what happens on duplicate folder names. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: the first states the purpose, and the second provides additional context. It's front-loaded with the core functionality. However, the second sentence could be more directly actionable, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (creation operation with one parameter) and the presence of annotations and an output schema, the description is minimally adequate. It covers the 'what' but lacks details on 'how' to use it effectively, such as parameter constraints or interaction with sibling tools. The output schema likely handles return values, so that gap is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't mention parameters at all. The schema defines a single required 'name' parameter with a description 'Folder name', but the tool description adds no semantic context beyond what's in the schema. With 0% coverage, the description fails to compensate, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Create a new project folder', specifying the verb (create) and resource (project folder). It distinguishes from siblings like 'ticktick_create_project' by focusing on folders rather than projects. However, it doesn't explicitly contrast with 'ticktick_update_folder' or 'ticktick_list_folders', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Folders help organize projects into logical groups', which implies a use case but doesn't specify when to use this tool versus alternatives like 'ticktick_create_project' for creating projects directly or 'ticktick_update_folder' for modifying existing folders. No explicit when/when-not instructions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond what annotations provide. Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive or idempotent. The description mentions organizational features (folders, view modes) which provide some context about project capabilities, but doesn't address important behavioral aspects like authentication requirements, rate limits, or what happens on duplicate project names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with two sentences. The first sentence directly states the purpose, and the second adds relevant context about project organization. There's no wasted verbiage, though the structure could be slightly improved by front-loading more critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a creation tool with no destructive hint and an output schema exists, the description is minimally adequate. However, for a tool that creates a primary entity in a task management system, more context about project capabilities, constraints, or relationships to other entities would be helpful. The description covers basic purpose but leaves many contextual questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of explaining parameters but provides no parameter information whatsoever. The schema itself has excellent parameter descriptions (name, color format, folder_id purpose, view_mode options), so the baseline is 3 since the schema does the heavy lifting despite the description adding zero value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new project/list'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'ticktick_create_folder' or 'ticktick_create_task', which also create different types of entities in the same system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of prerequisites, when this should be used instead of other creation tools, or any contextual constraints. The second sentence describes project capabilities but doesn't inform usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, indicating this is a non-idempotent write operation that doesn't destroy data. The description adds the API version requirement, which is useful behavioral context not covered by annotations, but doesn't mention other traits like authentication needs, rate limits, or what happens on duplicate creation attempts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that both earn their place: the first states the core purpose, the second provides important API requirement context. No wasted words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters, 0% schema description coverage, no output schema mentioned in context signals (though input schema shows one exists), and annotations covering only basic hints, the description is insufficient. It doesn't explain parameter meanings, relationships between parent_task_id and project_id, expected return values, or error conditions. The API version note helps but doesn't compensate for major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (the schema has descriptions but context signals indicate 0% coverage), the description carries full burden for parameter documentation. It mentions only that this creates a subtask 'under a parent task,' which hints at the parent_task_id parameter but doesn't explain any of the 6 parameters (parent_task_id, project_id, title, content, due_date, priority) or their relationships. This is inadequate compensation for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a subtask') and the target ('under a parent task'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_create_task' beyond the parent-child relationship implication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context with the note about requiring v2 API for full hierarchy support, which implies when this tool should work. However, it doesn't explicitly state when to use this versus alternatives like 'ticktick_create_task' or mention prerequisites beyond the API version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating this is a safe, non-destructive read operation. The description adds the authentication requirement ('Requires v2 API authentication'), which is useful context not covered by annotations. However, it doesn't disclose other behavioral traits like rate limits, pagination, or error conditions. With annotations covering the safety profile, a 3 is appropriate as the description adds some value but not rich 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, and the second adds authentication context. There's no wasted verbiage, and both sentences earn their place by providing essential information. However, it could be slightly improved by integrating the authentication note more seamlessly or adding a brief usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a filtered read operation), the description is somewhat complete but has gaps. Annotations cover safety, and there's an output schema (though not provided here), so the description needn't explain return values. However, it lacks guidance on when to use this tool versus siblings, and parameter semantics are weak. For a tool with authentication requirements and sibling alternatives, this is adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description doesn't compensate by explaining parameters. It mentions 'a specific tag' which aligns with the 'tag_name' parameter, but doesn't detail the 'include_completed' parameter or provide any syntax or format guidance. With no parameter info in the description, and given the schema's lack of descriptions, this meets the baseline of 3 for minimal coverage, but doesn't add meaningful semantics beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all tasks that have a specific tag.' This is a specific verb ('Get') + resource ('tasks') + qualifier ('with a specific tag'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_list_tasks' or 'ticktick_get_completed_tasks', which might also retrieve tasks with different filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions 'Requires v2 API authentication,' which is a prerequisite but not a usage context. There's no indication of when to use this tool versus alternatives like 'ticktick_list_tasks' (which might list all tasks without tag filtering) or 'ticktick_get_completed_tasks' (which focuses on completed tasks). The agent is left to infer usage based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false (indicating mutation), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description doesn't contradict these but adds minimal context beyond them—it specifies 'existing project's properties,' implying the need for a pre-existing project. However, it doesn't disclose additional behavioral traits like authentication requirements, rate limits, or what happens to unspecified properties. With annotations covering core safety, the description adds some value but could be more informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Update an existing project's properties'), making it easy to scan. Every part of the sentence serves a purpose, and there's no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation tool with 1 parameter but nested properties), annotations cover safety aspects (non-destructive, idempotent), and there's an output schema (so return values are documented elsewhere). However, the description lacks details on parameter semantics and usage context. It's minimally adequate but has clear gaps, especially with 0% schema description coverage and no sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters have descriptions in the schema. The description mentions 'properties' generically but doesn't detail specific parameters like project_id, name, color, etc. It adds minimal meaning beyond the schema's property names. With 0% coverage, the description should compensate more but only provides a high-level overview, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing project's properties' clearly states the verb (update) and resource (project), but it's vague about what specific properties can be updated. It doesn't differentiate from sibling tools like ticktick_update_folder or ticktick_update_task, which have similar update operations on different resources. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing project ID), when not to use it (e.g., for creating new projects, which is ticktick_create_project), or how it differs from other update tools in the sibling list. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true and idempotentHint=true, indicating this is a non-reversible operation that can be safely retried. The description adds valuable context with the warning 'This action cannot be undone,' reinforcing the destructive nature and providing user-facing caution beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the purpose and another providing a critical warning. It is front-loaded with the main action and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive batch operation), annotations cover safety (destructive, idempotent), and an output schema exists, reducing the need for return value details. However, the description lacks parameter guidance and usage context, making it minimally adequate but with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with no descriptions for the 'tasks' array or its items. The description does not compensate by explaining what 'tasks' should contain (e.g., task IDs, project IDs) or the format, leaving parameters largely undocumented beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete multiple tasks') and scope ('in a single request'), which is specific and distinguishes it from the sibling 'ticktick_delete_task' that likely handles single deletions. However, it doesn't explicitly mention the resource type (tasks) beyond the name, though this is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_delete_task' for single deletions or other deletion tools. It lacks context about prerequisites, such as needing task IDs, or when batch deletion is preferred over individual calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, indicating it's a non-destructive, repeatable mutation. The description adds minimal context by specifying the action involves moving between projects/lists, but doesn't elaborate on behavioral traits like permissions needed, effects on task metadata, or error conditions. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the core action ('Move a task') and specifies the destination efficiently. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation with three parameters), annotations cover safety (non-destructive, idempotent), and an output schema exists (not detailed here), the description is minimally adequate. However, it lacks context on prerequisites, error handling, or output expectations, leaving gaps for an agent to infer correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the input schema's properties (task_id, from_project_id, to_project_id) are self-explanatory with titles and descriptions. The description mentions moving 'to a different project/list', aligning with the parameters but not adding significant meaning beyond what the schema implies. With one parameter object containing three fields, the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and resource ('a task'), specifying the destination ('to a different project/list'). It distinguishes from sibling tools like 'ticktick_update_task' by focusing on relocation rather than content modification. However, it doesn't explicitly contrast with tools like 'ticktick_create_task' or 'ticktick_delete_task' in terms of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing valid project IDs), exclusions (e.g., not for moving subtasks), or comparisons to siblings like 'ticktick_update_task' for changing task properties instead of location. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering basic safety and idempotency. The description adds valuable context about authentication requirements ('Requires v2 API authentication') and behavioral characteristics ('open-ended focus tracking without a fixed duration'), which aren't captured in annotations. However, it doesn't describe what happens when starting multiple sessions, error conditions, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three brief sentences that each add value: stating the action, explaining the behavioral characteristic, and specifying authentication requirements. There's zero wasted text, and it's front-loaded with the core purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has annotations covering basic hints and an output schema exists (though not shown), the description provides adequate context for a simple start operation. However, with 0% schema description coverage and no parameter explanation in the description, there's a significant gap in understanding how to use the tool effectively. The description covers authentication and behavioral context but leaves parameters unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description mentions no parameters at all, failing to explain what 'task_id' or 'task_title' represent or how they affect the stopwatch session. With 1 parameter (a nested object with 2 sub-parameters) and zero coverage, the description should compensate but doesn't, leaving parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start a stopwatch focus session') and resource ('focus session'), making the purpose immediately understandable. It distinguishes from sibling tools like 'ticktick_start_pomodoro' by specifying 'open-ended focus tracking without a fixed duration', though it doesn't explicitly name alternatives. The description avoids tautology by not just restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'open-ended focus tracking without a fixed duration' and 'Requires v2 API authentication', which helps understand when this tool is appropriate. However, it doesn't explicitly state when to use this versus alternatives like 'ticktick_start_pomodoro' or 'ticktick_stop_focus', nor does it mention prerequisites beyond authentication. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description adds that it reopens completed tasks, which implies a state change not covered by annotations. However, it lacks details on permissions, side effects, or error conditions. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('Reopen a completed task') and adds a clarifying parenthetical. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with annotations covering safety (idempotent, non-destructive), an output schema exists (not detailed here), and schema documenting parameters, the description is minimally adequate. It states what the tool does but lacks context on usage, errors, or output, leaving gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the input schema's properties have descriptions: 'task_id' and 'project_id' are documented there. The description adds no parameter information beyond implying a task ID is needed. With schema doing the work, baseline 3 is appropriate, though the description could have clarified parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Reopen') and resource ('a completed task'), with additional clarification ('mark as incomplete'). It distinguishes from siblings like 'ticktick_complete_task' by indicating the opposite action. However, it doesn't specify the exact effect on task status or mention the sibling tool by name, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., task must be completed), exclusions, or compare it to related tools like 'ticktick_update_task' for status changes. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide key behavioral hints: readOnlyHint=false (indicates mutation), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description adds minimal context by specifying 'rename' as the action, but doesn't elaborate on permissions needed, error conditions, or what happens to existing folder contents. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence ('Rename a project folder.'), which is front-loaded and wastes no words. Every word earns its place by directly stating the tool's core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation operation), rich annotations (covering safety and idempotency), and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context about usage scenarios, error handling, or how it integrates with sibling tools, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'rename' but doesn't detail parameters. The input schema has 100% description coverage (both 'folder_id' and 'name' are well-described), so the baseline is 3. The description doesn't add meaningful semantic context beyond what the schema already provides about these two required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a project folder' clearly states the verb (rename) and resource (project folder), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'ticktick_update_project' or 'ticktick_update_tag', which have similar naming patterns for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of prerequisites (like needing an existing folder), when not to use it, or how it differs from related tools such as 'ticktick_update_project' (which might update other project attributes) or 'ticktick_create_folder' (for creating new folders).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering key behavioral traits. The description adds useful context about partial updates ('Only provided fields will be updated'), which isn't in annotations. However, it doesn't mention authentication requirements, rate limits, or what happens with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences, both of which add value. The first sentence states the core purpose, and the second provides important behavioral context about partial updates. There's zero wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with annotations covering safety (destructiveHint=false, idempotentHint=true) and an output schema exists, the description provides minimal but useful context. However, it doesn't explain what fields can be updated, doesn't mention required parameters (task_id, project_id), and offers no usage guidance relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are completely undocumented in the schema. The description doesn't mention any parameters beyond the generic 'fields', failing to explain what fields can be updated or their formats. However, since there's only 1 parameter (a nested object), the baseline is higher than for tools with many undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing task'), making the purpose immediately understandable. It distinguishes from sibling tools like 'ticktick_create_task' by specifying it's for existing tasks, though it doesn't explicitly contrast with other update tools like 'ticktick_update_project' or 'ticktick_update_folder'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (like needing task_id and project_id), doesn't differentiate from other update tools (update_project, update_folder), and offers no context about when this is appropriate versus tools like 'ticktick_complete_task' or 'ticktick_move_task'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation, which the description doesn't contradict. The description adds some behavioral context by mentioning the default inbox behavior when project_id is omitted, but doesn't provide additional details about authentication requirements, rate limits, error conditions, or what happens with duplicate tasks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with three sentences that are front-loaded with the main purpose. Each sentence adds value: the first states the core function, the second lists key parameters, and the third provides important default behavior. There's minimal wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a creation tool with 11 parameters (0% schema coverage) and no output schema, the description provides basic but incomplete coverage. It mentions the existence of an output schema (context signals indicate 'Has output schema: true'), so it doesn't need to describe return values, but it leaves many parameters unexplained and lacks behavioral details for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions several parameters (title, description, due date, priority, tags, project_id) and provides semantic context about the project_id default behavior. However, with 0% schema description coverage, the schema provides no parameter descriptions, so the description only partially compensates for 11 parameters. It doesn't explain parameters like start_date, is_all_day, time_zone, repeat_flag, or pomo_estimated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 task') and resource ('in TickTick'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'ticktick_batch_create_tasks' or 'ticktick_create_subtask', which would require more specific scope information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by explaining that 'If project_id is not provided, task goes to inbox,' which helps understand when to use this parameter. However, it doesn't offer explicit guidance on when to choose this tool over alternatives like batch creation or subtask creation, nor does it mention any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds value by specifying the authentication requirement ('Requires v2 API authentication'), which isn't covered by annotations. However, it doesn't disclose additional behavioral traits like rate limits, error handling, or response format details, limiting its transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, with two sentences that efficiently convey the tool's purpose and authentication requirement. Every sentence adds value without redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of annotations and an output schema, the description is reasonably complete. It covers the core purpose and authentication needs, which are essential for usage. However, it lacks guidance on when to use this tool over siblings, slightly reducing completeness for an agent needing to choose between similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for parameters. The description doesn't add any parameter-specific information beyond the schema, such as explaining what 'habit_id' represents or its format. With one parameter and no schema descriptions, the baseline is 3, as the description doesn't compensate for the lack of schema details but also doesn't worsen the situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific habit including its statistics.' This specifies the verb ('Get'), resource ('habit'), and scope ('details' and 'statistics'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_get_habit_stats' or 'ticktick_get_today_habits', which might cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance with 'Requires v2 API authentication,' which is a prerequisite but not a contextual guideline. It doesn't indicate when to use this tool versus alternatives like 'ticktick_list_habits' for listing habits or 'ticktick_get_habit_stats' for statistics, leaving the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds minimal behavioral context beyond this, specifying that it includes tasks in the output, which is useful but not rich. It doesn't describe response format, error conditions, or authentication needs, though annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose ('Get details of a specific project') and adds a useful detail ('including its tasks') efficiently. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter), rich annotations (covering safety and idempotency), and the presence of an output schema (which handles return values), the description is reasonably complete. It specifies the scope (project with tasks), though it could better address usage context. For a simple read tool, this is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't add any parameter details beyond what's implied by the tool name. It mentions 'a specific project' but doesn't explain the 'project_id' parameter's format, source, or constraints. With one parameter and no schema descriptions, the baseline is 3 as the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific project including its tasks'), making the purpose understandable. It distinguishes this from sibling tools like 'ticktick_list_projects' (which lists projects) by specifying retrieval of a single project with tasks. However, it doesn't explicitly differentiate from 'ticktick_get_task' (which gets a single task), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a project ID from 'ticktick_list_projects'), exclusions, or comparisons to similar tools like 'ticktick_get_task' or 'ticktick_list_tasks'. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds minimal behavioral context by mentioning filtering capabilities, but doesn't disclose aspects like pagination, rate limits, or authentication needs, which could be useful for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the purpose and another listing filters. Every word serves a purpose, and it's front-loaded with the core functionality, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that annotations cover safety (read-only, non-destructive, idempotent), the input schema is detailed, and an output schema exists, the description is reasonably complete for a list tool. It could improve by mentioning sibling tool relationships or output format hints, but it's sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description lists filtering options (project, priority, tags, search query), which aligns with the parameters in the schema. However, it doesn't add details beyond what the schema's parameter descriptions provide (e.g., format for priority values), so it meets the baseline for adequate but not enhanced coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('tasks') with optional filtering, which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_get_completed_tasks' or 'ticktick_get_task', which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools (e.g., 'ticktick_get_completed_tasks', 'ticktick_get_tag_tasks'), there's no indication of which tool is preferred for specific scenarios, leaving the agent to guess based on names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds minimal value by implying a status check without side effects, but it doesn't disclose additional behavioral traits like rate limits, error conditions, or what 'authentication status details' entail beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with the core purpose stated in the first sentence and a brief note on returns. There is no wasted language, and it efficiently communicates the essential information in a structured manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, annotations covering safety, and an output schema for return values), the description is reasonably complete. It states the purpose and hints at the output, though it could benefit from more context on usage scenarios. The annotations and output schema reduce the burden on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately avoids redundancy. A baseline of 4 is assigned as it meets expectations without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Check current authentication status,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate itself from sibling tools like 'ticktick_login' or 'ticktick_authorize_oauth,' which are related to authentication but serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., after login attempts), timing (e.g., before other operations), or comparisons to siblings like 'ticktick_login' for initial authentication. This leaves the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering basic safety and idempotency. The description adds context with 'Requires v2 API authentication,' which is useful for auth needs not covered by annotations. However, it doesn't disclose additional behavioral traits like rate limits, error handling, or what happens on duplicate check-ins, missing opportunities to enhance transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with three short sentences: 'Record a habit check-in.' states the purpose, 'Track your daily progress toward habit goals.' adds context, and 'Requires v2 API authentication.' provides a prerequisite. Each sentence earns its place without redundancy, and the structure is front-loaded with the core action, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations covering read/write and idempotency, an output schema exists (though not detailed here), and parameters are minimal (3 with 0% coverage), the description is somewhat complete but lacks depth. It covers purpose and auth needs but misses parameter explanations and behavioral details like return values or error cases. For a mutation tool with low schema coverage, it should do more to compensate, resulting in an average score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters (habit_id, value, date) are undocumented in the schema. The description doesn't add any parameter-specific information beyond the tool's general purpose, failing to compensate for the low coverage. Since there are 3 parameters, the baseline is lower than if coverage were high, but the description provides no details on what habit_id refers to or how value and date are used, resulting in a minimal score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Record a habit check-in' and 'Track your daily progress toward habit goals,' which specifies the verb (record/check-in) and resource (habit). It distinguishes from siblings like ticktick_get_habit or ticktick_update_habit by focusing on progress tracking rather than retrieval or modification. However, it doesn't explicitly contrast with ticktick_get_today_habits or ticktick_get_habit_stats, which might be related for viewing habits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Track your daily progress toward habit goals,' suggesting it's for logging habit completion, and 'Requires v2 API authentication' provides a prerequisite. However, it doesn't explicitly say when to use this tool versus alternatives like ticktick_update_habit for modifying habits or ticktick_get_today_habits for viewing today's habits, leaving some ambiguity in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent operations, which the description doesn't repeat, avoiding redundancy. It adds valuable context by specifying 'Requires v2 API authentication (username/password login)', which is crucial behavioral information not covered by annotations. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds essential authentication details in the second. Both sentences earn their place by providing critical information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving filtered tasks), annotations cover safety (read-only), and an output schema exists, the description is adequate but incomplete. It lacks details on return values (handled by output schema) and usage context, but the authentication note adds necessary context, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't detail parameters beyond implying a date range. It mentions 'within a date range', hinting at 'from_date' and 'to_date', but doesn't explain other parameters like 'project_id' or 'limit'. This partial compensation is minimal, aligning with the baseline for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('completed tasks within a date range'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_list_tasks' or 'ticktick_get_task', which might also retrieve tasks but with different filters or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mentions authentication requirements but doesn't specify scenarios where this tool is preferred over other task-retrieval tools in the sibling list, such as for historical analysis or filtering by completion status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, repeatable read operation. The description adds value by specifying the analytics content ('priority distribution, due date analysis, and tag usage'), which helps the agent understand what data to expect. However, it doesn't disclose behavioral traits like rate limits, authentication needs, or response format beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear purpose statement followed by a bullet-like list of analytics types. Every sentence earns its place with no wasted words. It's front-loaded with the main action and efficiently specifies the scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 input fields, annotations covering safety, and an output schema exists), the description is reasonably complete. It explains what analytics are returned, which complements the output schema. However, it could be more complete by mentioning the data scope (e.g., all tasks vs. filtered) or typical use cases, though the output schema likely handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the parameter is an empty object (no actual input fields). The description doesn't need to explain parameters since there are none to document. It appropriately focuses on the tool's output semantics. Baseline for 0 parameters is 4, as the description compensates by detailing what analytics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Get detailed task analytics' and specifies the types of analytics provided ('priority distribution, due date analysis, and tag usage'). It distinguishes from siblings like 'get_completed_tasks' or 'get_overview' by focusing on analytics rather than raw task data. However, it doesn't explicitly differentiate from 'get_weekly_report' or 'get_productivity_score', which might also provide analytical insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites, context (e.g., for planning vs. reporting), or compare it to siblings like 'get_weekly_report' or 'get_overview'. The agent must infer usage based on the name and description alone, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context about API version requirements ('Requires v2 API for complete data'), which is useful behavioral information not in annotations. However, it doesn't disclose other traits like rate limits, authentication needs, or response format, keeping the score moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences that are front-loaded with the main purpose. Each sentence adds value: the first states the action, the second details content, and the third specifies a requirement. There's no wasted text, though minor improvements in structure (e.g., bullet points) could enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), rich annotations (readOnly, idempotent, non-destructive), and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, content, and a key requirement, though it could benefit from more explicit usage guidelines to reach a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't mention the 'week_offset' parameter at all, failing to compensate for the schema gap. Since there's only one parameter, the baseline is 4, but the description adds no parameter semantics, so it's penalized to 3 for not providing any value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('weekly productivity report') with specific content details ('daily breakdown, totals, and trends'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_get_daily_summary' or 'ticktick_get_productivity_score', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an implicit usage guideline ('Requires v2 API for complete data'), which suggests a prerequisite for optimal use. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs. 'ticktick_get_daily_summary' for daily data or 'ticktick_get_productivity_score' for scores), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies that projects in the folder will be moved to root level rather than deleted. Annotations already indicate this is destructive and idempotent, but the description provides important operational details about the side effect. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise: two sentences that each provide essential information. First sentence states the core action, second sentence explains the key behavioral consequence. No wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with good annotations (destructiveHint, idempotentHint) and an output schema, the description provides sufficient context. It explains the main behavioral consequence (projects moved to root), which is the most important information beyond what annotations convey. The main gap is lack of parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't mention the 'folder_id' parameter at all. While the schema provides basic parameter documentation, the description adds no parameter-specific context. With only one parameter, the baseline is 4, but the description's complete lack of parameter information reduces this to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a project folder') and specifies what happens to contained projects ('Projects in the folder will be moved to the root level'). It distinguishes from sibling tools like 'delete_project' by focusing on folders rather than projects, though it doesn't explicitly contrast with 'update_folder' or 'create_folder'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'delete_project' or 'update_folder'. It mentions the consequence of moving projects to root, but doesn't specify prerequisites, permissions needed, or when this operation is appropriate versus deleting projects individually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds the authentication requirement ('Requires v2 API authentication') which provides useful context beyond annotations. However, it doesn't describe rate limits, error conditions, or response 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero waste: purpose statement, statistics details, and authentication requirement. Each sentence earns its place, and the structure is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that annotations cover safety profile (read-only, idempotent, non-destructive), schema documents parameters well, and there's an output schema (mentioned in context signals), the description provides adequate context. It covers purpose, statistics included, and authentication requirements. The main gap is lack of explicit sibling tool differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the input schema has good descriptions for all parameters (habit_id, from_date, to_date). The description doesn't add any parameter-specific information beyond what's already in the schema. With comprehensive schema documentation, the baseline score of 3 is appropriate as the description doesn't compensate but the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'statistics for a specific habit', with specific examples of what statistics are included (completion rate, streaks, historical data). It doesn't explicitly distinguish from sibling tools like 'ticktick_get_habit' or 'ticktick_get_today_habits', but the focus on statistics is clear and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Requires v2 API authentication' which provides some usage context, but doesn't explicitly state when to use this tool versus alternatives like 'ticktick_get_habit' (which might return basic habit info) or 'ticktick_get_today_habits' (which might show today's habits). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds useful context about authentication requirements for extended features, which isn't captured in annotations. However, it doesn't describe response format, error conditions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three brief sentences with clear information hierarchy: primary purpose first, content details second, authentication note third. No wasted words, though the authentication sentence could be slightly more integrated with the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (read-only, no parameters, has output schema), the description provides adequate context. It covers what data is returned and authentication requirements. The output schema will handle return value documentation, so the description doesn't need to explain response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and only one parameter (an empty object 'params'). The description doesn't mention any parameters, which is appropriate since the tool appears to require no specific input beyond authentication context. This earns a baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get today's productivity overview' with specific components (task status, habit progress, focus statistics). It distinguishes from siblings like 'ticktick_get_daily_summary' or 'ticktick_get_weekly_report' by focusing on today's overview, but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'today's' and mentions authentication requirements for extended features, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'ticktick_get_daily_summary' or 'ticktick_get_completed_tasks'. The authentication note is helpful but not comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds value by specifying the return format ('project details including ID, name, color, and task count'), which isn't covered by annotations, but doesn't mention pagination, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences, front-loading the core action ('List all projects/lists') and following with return details. Every word serves a purpose with zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a simple list operation), rich annotations (covering safety and idempotency), and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It specifies the resource scope and return fields, though it could benefit from mentioning the optional archived parameter or authentication context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't mention any parameters. The single parameter 'include_archived' is documented only in the schema with a clear description. Since the description adds no parameter semantics beyond the schema, and the schema does the heavy lifting, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all projects/lists'), making the purpose specific and unambiguous. It distinguishes this tool from other list operations (like ticktick_list_tasks or ticktick_list_folders) by specifying it's for projects/lists, not tasks or folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention when to prefer this over ticktick_get_project (for single project details) or ticktick_list_tasks (for tasks within projects), nor does it discuss prerequisites like authentication status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation (readOnlyHint=false, idempotentHint=false, destructiveHint=false), which the description aligns with by implying creation. It adds valuable context beyond annotations by specifying authentication requirements ('Requires v2 API authentication'), which is crucial for usage. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three brief sentences that are front-loaded and waste-free. Each sentence adds value: the first states the purpose, the second outlines key features, and the third specifies authentication requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation with multiple parameters) and the presence of an output schema (which handles return values), the description is partially complete. It covers purpose and authentication but lacks details on parameter usage, error handling, or behavioral nuances. With 0% schema description coverage, the description doesn't fully compensate for the missing parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description provides high-level parameter context by mentioning 'daily goals, reminders, and custom icons/colors', which maps to parameters like goal, reminder_time, color, and icon. However, it doesn't detail specific semantics, constraints, or formats for these parameters, leaving gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 habit') and the resource ('habit to track'), making the purpose evident. It distinguishes from siblings like 'ticktick_update_habit' by focusing on creation rather than modification, though it doesn't explicitly contrast with other creation tools like 'ticktick_create_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for habit creation with daily goals and reminders, and mentions authentication requirements ('Requires v2 API authentication'). However, it lacks explicit guidance on when to use this versus alternatives like 'ticktick_create_task' for tasks or 'ticktick_update_habit' for modifications, and doesn't specify prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond what annotations provide. Annotations show destructiveHint=true and idempotentHint=true, but the description explicitly warns 'This cannot be undone' (enhancing the destructive nature) and specifies 'Requires v2 API authentication' (adding permission/version context not in annotations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three short, front-loaded sentences that each add value: the core action, a critical warning, and an authentication requirement. There's zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with good annotations and an output schema (which handles return values), the description covers the essential behavioral warnings and authentication needs. The main gap is lack of usage guidance relative to sibling tools, but otherwise it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (the schema only has generic 'Input for deleting a focus record'), the description provides no parameter information at all. However, there's only one parameter (record_id), so the baseline is 4, but the description doesn't compensate for the schema gap, so it scores 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'focus record', making the purpose immediately understandable. However, it doesn't differentiate this from sibling deletion tools like delete_folder, delete_habit, delete_project, delete_tag, or delete_task, which all follow the same pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While it mentions authentication requirements, it doesn't explain when deletion is appropriate versus archiving or other operations, nor does it reference sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating this is a safe, non-destructive read operation. The description adds useful context by explaining that 'Folders are used to organize projects,' which helps the agent understand the organizational role of folders. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which are directly relevant. The first sentence states the core purpose, and the second provides helpful context about folder usage. There is no wasted verbiage or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a read-only list operation with no parameters), the description combined with annotations and the presence of an output schema provides sufficient context. The description explains what folders are and that they're being listed, which is adequate for this low-complexity tool. A minor gap is the lack of guidance on when to use versus siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the parameter is an empty object (no actual input fields). The description doesn't need to explain parameters since there are none to document. This meets the baseline for tools with 0 parameters, as the schema already indicates no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('all project folders'), and explains what folders are used for. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_list_projects' or 'ticktick_list_tags', which have similar listing functions for different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention sibling tools like 'ticktick_get_project' for single project retrieval or 'ticktick_list_projects' for listing projects instead of folders, nor does it specify any prerequisites or contextual constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only, idempotent, or destructive, which the description doesn't contradict. The description adds valuable context beyond annotations: it specifies that it 'Requires v2 API authentication,' which is crucial for usage, and mentions linking to tasks, clarifying functionality. It could improve by noting potential side effects like starting a timer that might conflict with existing sessions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by supporting details in bullet-like sentences. Each sentence adds value, such as authentication requirements and task linking, with no wasted words. It could be slightly more structured but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (starting a focus session), annotations cover safety aspects, and an output schema exists (though not provided here), the description is reasonably complete. It includes key usage notes like authentication and task linking. However, it could benefit from mentioning output expectations or error conditions to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't detail parameters beyond mentioning 'customizable duration' and linking to tasks. The input schema fully documents parameters like 'duration_minutes' and 'task_id' with descriptions, so the description adds minimal value. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start a Pomodoro focus session') and the resource ('Pomodoro focus session'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_start_stopwatch' or 'ticktick_stop_focus', which are related but distinct focus-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context by mentioning 'The classic Pomodoro technique with customizable duration' and 'Can be linked to a specific task,' which implies when to use it. However, it lacks explicit guidance on when to choose this tool over alternatives like 'ticktick_start_stopwatch' or when not to use it, such as if a focus session is already active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies authentication requirements ('Requires v2 API authentication'), which annotations don't cover. Annotations already indicate this is a non-destructive, idempotent mutation (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description doesn't contradict these. However, it doesn't mention rate limits, error conditions, or what happens when properties aren't specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both front-loaded with essential information: the core purpose and authentication requirement. There's no wasted text, repetition, or unnecessary elaboration. Every word serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 1 parameter (a nested object with 3 sub-properties), 0% schema description coverage, but with annotations covering safety (non-destructive, idempotent) and an output schema existing, the description is minimally adequate. It covers authentication and general purpose but lacks details on parameter usage, error handling, or sibling differentiation, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'properties (color, etc.)', which hints at the 'color' parameter and suggests other properties exist, but doesn't detail the 'name' (required current name) or 'new_name' parameters. It adds minimal semantic value beyond the bare schema, failing to fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a tag's properties'), with specific examples ('color, etc.'). It distinguishes from sibling tools like 'ticktick_create_tag' and 'ticktick_delete_tag' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from 'ticktick_rename_tag', which appears to be a more specific update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'Requires v2 API authentication', which is a prerequisite. However, it doesn't explicitly guide when to use this tool versus alternatives like 'ticktick_rename_tag' (which might handle name changes specifically) or 'ticktick_merge_tags'. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false (mutation), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description adds valuable context: it specifies that archived projects are hidden but restorable, and requires v2 API authentication. This enhances understanding beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: three brief sentences that are front-loaded with the core purpose, followed by behavioral and authentication details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation with idempotency), annotations cover key behavioral traits, and an output schema exists (reducing need to describe returns). The description adds useful context on archiving effects and authentication, though it could benefit from more explicit usage guidelines relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter ('project_id') documented only in the schema. The description doesn't add any parameter-specific details, such as format or sourcing of project_id. Baseline is 3 since the schema covers the parameter, but the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive a project') with a specific verb and resource. It distinguishes from sibling tools like 'ticktick_delete_project' by explaining that archived projects are hidden but restorable, though it doesn't explicitly compare to alternatives like 'delete_project' or 'update_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when hiding a project without permanent deletion, as it notes archived projects can be restored. However, it lacks explicit guidance on when to choose this over alternatives like 'delete_project' or 'update_project', and doesn't mention prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-idempotent write operation. The description adds value by noting efficiency benefits of batch creation, which is useful context beyond annotations. However, it doesn't disclose behavioral details like rate limits, error handling for partial failures, or authentication requirements, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two short sentences that directly state the purpose and key benefit. Every word earns its place with zero waste, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch creation with nested task objects) and the presence of a detailed input schema and output schema, the description is reasonably complete. It covers the core purpose and efficiency rationale. However, it could better address behavioral aspects like the 50-task limit or error scenarios, which would enhance completeness for this mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the input schema itself is well-documented with detailed property descriptions (e.g., 'Task title', 'Due date in ISO format'). The tool description doesn't add any parameter-specific information beyond what's in the schema. Since the schema carries the full burden, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create multiple tasks in a single request.' It specifies the verb ('create') and resource ('tasks'), and distinguishes it from the sibling tool 'ticktick_create_task' by emphasizing batch creation. However, it doesn't explicitly name the sibling alternative, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'More efficient than creating tasks one by one.' This implies when to use this tool (for multiple tasks) versus the single-task creation alternative. It doesn't explicitly name the alternative tool or mention constraints like the 50-task limit, but the context is sufficient for effective decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-readOnly, non-idempotent, non-destructive operation. The description adds valuable context beyond annotations by specifying authentication requirements ('Requires v2 API authentication') and nesting behavior ('Tags can be nested by specifying a parent tag name'). It doesn't contradict annotations and provides useful implementation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three sentences, each delivering essential information: core purpose, nesting capability, and authentication requirement. It's front-loaded with the main action and wastes no words. Every sentence earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), annotations cover safety profile, and the tool has only 1 required parameter, the description provides adequate context. It covers authentication requirements and nesting behavior which aren't in structured fields. For a simple creation tool with good annotations and output schema, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description doesn't mention any parameters directly. However, it implicitly explains the purpose of the 'parent_name' parameter through 'Tags can be nested by specifying a parent tag name'. This adds some semantic value, but doesn't cover 'name' or 'color' parameters. With 0% schema coverage, the description provides partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 tag') and resource ('tag'), making the purpose immediately understandable. It distinguishes from siblings like 'ticktick_rename_tag' or 'ticktick_delete_tag' by specifying creation rather than modification or deletion. However, it doesn't explicitly differentiate from 'ticktick_merge_tags' which also involves tag operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context through 'Tags can be nested by specifying a parent tag name' and 'Requires v2 API authentication', suggesting when to use nesting and authentication prerequisites. However, it lacks explicit guidance on when to choose this tool over alternatives like 'ticktick_update_tag' or 'ticktick_merge_tags', and doesn't mention any exclusions or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context beyond this: it specifies that deletion includes 'all check-in history' (clarifying scope) and mentions authentication requirements ('Requires v2 API authentication'), which aren't covered by annotations. This enhances the agent's understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear purpose statement followed by two critical warnings/requirements, each on separate lines. Every sentence earns its place by adding essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive deletion with one parameter), annotations cover safety (destructive, idempotent), and an output schema exists, the description provides sufficient context: it clarifies the scope of deletion and authentication needs. However, it could slightly improve by mentioning idempotency or linking to sibling tools for alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't add any parameter-specific information beyond the generic 'Delete a habit.' The schema itself documents the 'habit_id' parameter adequately. Since the parameter count is low (1) and the schema handles it, the baseline of 3 is appropriate, as the description doesn't compensate for the coverage gap but doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a habit'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling deletion tools like 'ticktick_delete_project' or 'ticktick_delete_task' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied guidance through warnings and requirements ('Warning: This will delete all check-in history for this habit. Requires v2 API authentication.'), suggesting when to be cautious. However, it lacks explicit alternatives (e.g., 'use ticktick_archive_project for reversible deletion') or clear when-not-to-use scenarios compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it clarifies the destructive scope ('removed from all tasks') and authentication requirements ('v2 API authentication'). Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description complements rather than contradicts, providing operational details that help the agent understand the tool's impact and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: three short sentences that are front-loaded with the core action, followed by critical behavioral and authentication details. Every sentence adds essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with authentication needs), the description covers key aspects: purpose, scope of deletion, and auth requirements. Annotations provide safety hints, and an output schema exists, so the description doesn't need to explain return values. It's mostly complete but could benefit from more explicit sibling differentiation or error handling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't add any parameter-specific information beyond the tool name implying a 'tag' parameter. The schema defines a 'name' parameter with its own description, so the description doesn't compensate for the low coverage. With 1 parameter, the baseline is 4, but since the description adds no param semantics, it drops to 3 for minimal adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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') and specifies the resource ('tag'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ticktick_rename_tag' or 'ticktick_merge_tags' which also operate on tags, missing an opportunity for precise sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'The tag will be removed from all tasks' and 'Requires v2 API authentication', suggesting when this tool is appropriate (for removing tags globally with specific auth). However, it doesn't explicitly state when to use this versus alternatives like 'ticktick_rename_tag' or provide clear exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies the data components included (tasks, habits, focus time) and mentions the 'v2 API' requirement, which are behavioral traits not captured in annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, followed by two supporting sentences that add specific details without waste. Every sentence earns its place by clarifying scope, data types, and requirements, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a read-only summary with one parameter) and the presence of annotations (covering safety) and an output schema (which handles return values), the description is mostly complete. It specifies the data included and API requirements, but could be more explicit about output format or error handling, though the output schema mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the input schema's 'date' parameter has a description: 'Date to summarize (YYYY-MM-DD, defaults to today).' The tool description doesn't add any parameter-specific information beyond what's in the schema, such as format details or constraints. With one parameter well-documented in the schema, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed summary for a specific day' with specific components listed ('tasks completed, habits done, and focus time'). It distinguishes itself from siblings like 'ticktick_get_completed_tasks' or 'ticktick_get_today_habits' by combining multiple data types into a daily summary, but doesn't explicitly contrast with all alternatives like 'ticktick_get_overview' or 'ticktick_get_weekly_report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'for a specific day' and mentioning 'Requires v2 API for complete data,' which suggests prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'ticktick_get_today_focus' or 'ticktick_get_weekly_report,' nor does it provide exclusions or detailed comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, repeatable read operation. The description adds valuable context beyond annotations by specifying authentication requirements ('Requires v2 API authentication'), which isn't covered by the annotations. It doesn't contradict annotations, and the added context is helpful for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences that are front-loaded and waste no words. Each sentence adds value: the first states the purpose, the second explains filtering, and the third specifies authentication requirements. This structure is efficient and easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has annotations covering safety (read-only, idempotent, non-destructive), an output schema exists (so return values are documented elsewhere), and the description adds key context like authentication and filtering, it's mostly complete. However, the 0% schema description coverage for parameters leaves some gaps in understanding input details, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions filtering by 'date range and focus type (pomodoro/stopwatch)', which maps to the 'from_date', 'to_date', and 'focus_type' parameters, providing some semantic meaning. However, it doesn't fully compensate for the lack of schema descriptions, as it omits details like parameter formats or optionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get focus session history' with a specific verb ('Get') and resource ('focus session history'), which distinguishes it from siblings like 'ticktick_get_today_focus' or 'ticktick_get_focus_settings'. However, it doesn't explicitly differentiate from all sibling tools beyond the general domain of focus records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning filtering capabilities ('Filter by date range and focus type') and authentication requirements ('Requires v2 API authentication'), but it doesn't explicitly state when to use this tool versus alternatives like 'ticktick_get_today_focus' or provide clear exclusions. The guidance is contextual but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds value by specifying the dual ID requirement, which isn't obvious from annotations alone. It doesn't contradict annotations (the 'Get' action aligns with readOnly), and provides practical constraint information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences, both essential. The first sentence states the core purpose, and the second provides critical prerequisite information. No wasted words, perfectly front-loaded, and structured for immediate comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple retrieval purpose, rich annotations (covering safety/idempotency), and existence of an output schema (which handles return values), the description provides adequate context. It covers the key operational constraint (dual ID requirement) that isn't captured elsewhere. For a read-only get operation, this is reasonably complete, though it could mention error cases or relationship to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining that both task_id and project_id are required. However, it doesn't provide additional semantic context beyond what's implied by parameter names (e.g., format of IDs, where to find them, or relationship between task and project). With one complex parameter object containing two required fields, the description adds basic clarity but leaves details to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific task by ID'), making the purpose immediately understandable. It distinguishes this from list/query tools like 'ticktick_list_tasks' by specifying retrieval of a single task. However, it doesn't explicitly contrast with other get operations like 'ticktick_get_project' or 'ticktick_get_habit'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'Requires both task ID and project ID,' which suggests prerequisites. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'ticktick_list_tasks' for browsing or 'ticktick_get_completed_tasks' for historical data. No when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate this is a non-destructive, idempotent mutation (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description specifies authentication requirements ('Requires v2 API authentication') which isn't covered by annotations. This helps the agent understand access prerequisites. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three short sentences that each serve a distinct purpose: stating the action, listing customizable elements, and specifying authentication requirements. There's zero wasted text, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with rich annotations (idempotent, non-destructive) and an output schema exists (though not shown), the description provides reasonable completeness. It covers the core purpose, key parameters at a high level, and critical authentication requirements. However, it could benefit from more detail about what 'automation preferences' specifically means and how partial updates work with null parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (the schema has no top-level description, only parameter-level descriptions), the description carries more burden. It mentions 'Customize work duration, breaks, and automation preferences' which maps to the parameters (pomo_duration, short_break, long_break, auto_start_break, auto_start_pomo) but doesn't cover all parameters (missing long_break_interval, daily_pomo_target). The description adds some semantic context but doesn't fully compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Update Pomodoro/focus settings' and specifies the resource being modified. It distinguishes from siblings like 'ticktick_get_focus_settings' by indicating this is an update operation rather than a read. However, it doesn't explicitly differentiate from other update tools (like update_task or update_project) beyond the focus settings scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'Requires v2 API authentication' which is helpful for prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives (like whether to use this versus configuring focus through other means) or provide clear exclusion criteria. The authentication requirement is useful but insufficient for full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by stating 'Delete a task permanently'. The description adds value by warning 'This action cannot be undone', providing crucial behavioral context beyond annotations about irreversibility. It doesn't mention idempotency (covered by annotations) or other traits like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: the first states the purpose, and the second provides a critical warning. Every word earns its place, and it's front-loaded with the core action, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (annotations show destructiveHint=true) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the irreversible action, but could benefit from mentioning sibling tools or prerequisites. The combination of description, annotations, and schema provides adequate context for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters, but the input schema has 100% description coverage (both 'task_id' and 'project_id' are well-described in the schema). With high schema coverage, the baseline is 3, but the description's brevity and focus on the action's permanence add some semantic context, justifying a slightly higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a task permanently') with the resource ('task'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_batch_delete_tasks' or 'ticktick_archive_project', which handle multiple tasks or different deletion methods, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The warning 'This action cannot be undone' implies this tool should be used cautiously for permanent deletion, but it doesn't provide explicit guidance on when to use this versus alternatives like 'ticktick_archive_project' or 'ticktick_batch_delete_tasks'. The context is implied rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations by specifying authentication requirements ('Requires v2 API authentication') and detailing what information is returned ('Shows work duration, break times, and daily goals'). This enhances behavioral understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: three short sentences that each add value. The first states the purpose, the second details the output, and the third specifies authentication requirements. There is no wasted language, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, read-only operation), rich annotations (readOnlyHint, idempotentHint, destructiveHint), and presence of an output schema, the description is mostly complete. It covers purpose, output details, and authentication. However, it could briefly mention the output schema's role to fully guide the agent, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the parameter is an empty object (no fields). The description doesn't need to explain parameters since there are none to document. Given 0 parameters, the baseline is 4, as the description appropriately focuses on the tool's purpose and behavior rather than non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Get current Pomodoro/focus settings' and specifies what information it retrieves ('Shows work duration, break times, and daily goals'). It distinguishes from siblings like 'ticktick_update_focus_settings' by being a read operation, but doesn't explicitly name alternatives. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'Requires v2 API authentication', which indicates a prerequisite. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'ticktick_get_today_focus' or 'ticktick_update_focus_settings', nor does it state when not to use it. The authentication requirement is helpful but not comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context: it discloses that extended metrics require v2 API authentication (an access requirement) and mentions personalized recommendations (output behavior). No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise: four brief sentences that each add distinct value (purpose, components, recommendations, authentication requirement). No wasted words, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no input parameters, annotations cover safety, output schema exists), the description provides adequate context: purpose, score components, recommendations, and authentication notes. The output schema will handle return values, so the description doesn't need to explain them. It could slightly improve by clarifying the scope (e.g., time period).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the parameter is an empty object (no actual input fields). The description doesn't need to explain parameters since there are none to document. This exceeds the baseline expectation for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Calculate your productivity score' with specific components (task completion, habit consistency, focus time). It distinguishes from sibling tools by focusing on productivity scoring rather than task/project management operations. However, it doesn't explicitly differentiate from other analytics tools like 'get_task_analytics' or 'get_weekly_report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'personalized recommendations' and 'Extended metrics require v2 API authentication,' suggesting when enhanced features are available. However, it doesn't provide explicit guidance on when to use this versus other analytics tools (get_task_analytics, get_weekly_report) or mention prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, repeatable read operation. The description adds valuable context beyond annotations: it specifies authentication requirements ('Requires v2 API authentication'), which is crucial for usage, and outlines what data is returned ('total focus time, pomodoro count, and progress toward daily goal'). No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: three brief sentences that are front-loaded with the core purpose, followed by details on returned data and authentication. Every sentence adds essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no input parameters, simple read operation) and rich annotations (readOnly, idempotent, non-destructive) plus an output schema (implied by 'Has output schema: true'), the description is mostly complete. It covers purpose, returned data, and authentication needs. However, it could slightly improve by mentioning the output format or any limitations (e.g., timezone considerations).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage with one parameter (an empty object 'params'), so the schema provides minimal semantic information. The description compensates by implicitly indicating no required input parameters beyond authentication, as it focuses on today's data without mentioning filters or options. This adequately clarifies the parameter semantics given the simple schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'Shows') and resources ('today's focus time statistics', 'total focus time, pomodoro count, and progress toward daily goal'). It distinguishes itself from siblings by focusing on today's focus stats rather than other time periods or task management functions. However, it doesn't explicitly contrast with similar tools like ticktick_get_focus_records or ticktick_get_daily_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'today's' focus statistics and mentions authentication requirements ('Requires v2 API authentication'), providing some guidance. However, it lacks explicit when-to-use directives compared to alternatives (e.g., vs. ticktick_get_focus_records for historical data or ticktick_get_daily_summary for broader daily metrics). No clear exclusions or sibling tool comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, non-mutating operation. The description adds value by specifying 'Shows which habits are completed and which need attention' (behavioral output detail) and 'Requires v2 API authentication' (auth requirement not in annotations). It doesn't contradict annotations, as 'Get' aligns with read-only, and no rate limits or side effects are mentioned, but the added context is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by additional context in two concise sentences. Every sentence adds value: the first states what it does, the second clarifies output behavior, and the third specifies auth requirements. There's zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, simple read operation), annotations cover safety (read-only, idempotent, non-destructive), and an output schema exists (so return values are documented elsewhere), the description is fairly complete. It adds purpose, output detail, and auth info. However, it could slightly improve by explicitly differentiating from siblings or mentioning any limitations (e.g., time zone considerations).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage (no details in schema). The description doesn't mention any parameters, but since there's only 1 parameter (likely a placeholder or minimal input), the baseline is high. It compensates by implying the tool fetches all habits for today without filtering, so no parameter details are needed, making it adequate for this simple case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get today's status for all habits' specifies the verb (get) and resource (today's habit status). It distinguishes from siblings like 'ticktick_get_habit' (single habit) and 'ticktick_list_habits' (list all habits without today's status), though not explicitly named. However, it doesn't fully differentiate from 'ticktick_get_habit_stats' which might overlap, keeping it at 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'today's status' and 'all habits', suggesting it's for daily habit tracking. It mentions 'Requires v2 API authentication' as a prerequisite. However, it doesn't explicitly state when to use this tool versus alternatives like 'ticktick_get_habit' or 'ticktick_list_habits', nor does it provide exclusions or detailed scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context about authentication requirements ('Requires v2 API authentication') that isn't captured in annotations, which is crucial for the agent to understand prerequisites. No behavioral contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality, the second provides critical authentication context. No wasted words, perfectly front-loaded, and appropriately sized for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list operation with no meaningful parameters), rich annotations covering safety/idempotency, and the existence of an output schema (which handles return values), the description is reasonably complete. It covers the core purpose and critical authentication requirement. The only minor gap is lack of explicit sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage (empty properties object). The description doesn't add any parameter-specific information, but since there are effectively 0 meaningful parameters (the single parameter appears to be a wrapper with no actual fields), this is acceptable. The baseline for 0 parameters would be 4, and the description doesn't detract from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'List all habits' - a specific verb ('List') and resource ('habits'). It distinguishes from siblings like 'ticktick_get_habit' (single habit) and 'ticktick_get_today_habits' (today-specific). However, it doesn't explicitly mention scope differences from 'ticktick_get_habit_stats' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context through the authentication requirement ('Requires v2 API authentication'), suggesting when authentication is needed. However, it lacks explicit guidance on when to use this tool versus alternatives like 'ticktick_get_today_habits' or 'ticktick_get_habit', and doesn't mention any prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds useful context about enabling extended features and v2 API access, but doesn't mention authentication requirements, session management, rate limits, or error behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose statement, benefit explanation, and parameter/return documentation. The structure is front-loaded with the core functionality, though the Args/Returns formatting could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication tool with annotations covering safety aspects and an output schema (implied by 'Returns: Success message'), the description provides adequate context about purpose and benefits. However, it lacks details about authentication flow, session duration, or error scenarios that would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the schema provides no parameter descriptions. The description only mentions 'Login credentials' generically and doesn't explain the username/password structure or requirements. However, the input schema itself clearly defines the two required fields, providing baseline documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Login with username/password'), target resource ('v2 API access'), and distinguishes from sibling tools like ticktick_authorize_oauth which uses OAuth authentication. It explicitly mentions the authentication method and API version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('for v2 API access' and 'enables extended features like tags, habits, and focus timer'), but doesn't explicitly state when NOT to use it or mention alternatives like ticktick_authorize_oauth for OAuth-based authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond this: it specifies authentication requirements ('Requires v2 API authentication') and behavioral options ('Optionally save or discard the focus record'), which aren't covered by annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three brief sentences, each adding distinct value: the core action, parameter guidance, and authentication requirement. It's front-loaded with the primary purpose and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, annotations covering safety/idempotency, and an output schema (which handles return values), the description is reasonably complete. It covers authentication needs and parameter meaning, though it could benefit from mentioning idempotency or error conditions for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the parameter's purpose: 'Optionally save or discard the focus record' clarifies the 'save' boolean parameter's semantics. This adds meaningful context beyond the schema's basic description, though it doesn't detail default behavior or implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop the current focus session') with a specific verb and resource. It distinguishes from siblings like 'ticktick_start_pomodoro' or 'ticktick_start_stopwatch' by indicating it ends a session rather than starting one. However, it doesn't explicitly differentiate from 'ticktick_delete_focus_record' which might also end sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a focus session is active, but doesn't explicitly state when to use it versus alternatives. It mentions optional saving/discarding, which provides some context, but lacks guidance on prerequisites or comparisons with other focus-related tools like 'ticktick_get_focus_records'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies that the source tag will be deleted and tasks moved to the target tag, which clarifies the 'destructiveHint: true' annotation. It also mentions the v2 API authentication requirement, which isn't covered by annotations. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose, followed by two sentences adding critical behavioral and authentication details. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (destructive merge operation), the description covers key aspects: purpose, behavioral effects (deletion/task transfer), and authentication requirements. With annotations providing safety hints and an output schema presumably handling return values, the description is largely complete, though it could benefit from more parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description doesn't add parameter details beyond what's implied by the tool's purpose. It mentions 'source tag' and 'target tag' generally but doesn't explain their formats or constraints. With no schema descriptions, a baseline of 3 is appropriate as the description provides minimal parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('merge one tag into another') and resource (tags), distinguishing it from sibling tools like 'ticktick_rename_tag' or 'ticktick_delete_tag' by specifying the transfer of tasks and deletion of the source tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (merging tags with task transfer) and implicitly suggests alternatives like 'ticktick_rename_tag' for renaming without merging or 'ticktick_delete_tag' for deletion without transfer, though it doesn't explicitly name these alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies that renaming updates all tasks with the old tag to the new name (clarifying the scope of change) and mentions the authentication requirement ('Requires v2 API authentication'). Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which the description does not contradict, so no annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured: three brief sentences that are front-loaded with the core purpose, followed by important behavioral and authentication details. Every sentence adds essential information without any waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation operation with side effects), the description is mostly complete: it covers purpose, behavioral impact, and authentication. Annotations provide safety hints, and an output schema exists (though not detailed in the context), reducing the need to explain return values. However, it could briefly mention idempotency or error cases for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema, which has 0% schema description coverage but defines parameters 'old_name' and 'new_name' clearly with titles and descriptions. Since the schema coverage is low, the description could compensate by explaining parameter roles or constraints, but it does not, resulting in a baseline score of 3 as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Rename a tag') and distinguishes it from sibling tools like 'ticktick_create_tag', 'ticktick_delete_tag', 'ticktick_update_tag', and 'ticktick_merge_tags' by focusing on renaming rather than creating, deleting, updating other properties, or merging. The verb 'rename' is precise and the resource 'tag' is explicitly identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 needing to rename a tag, with the implication that it affects all associated tasks. However, it does not explicitly state when not to use it or name alternatives (e.g., using 'ticktick_update_tag' for other modifications or 'ticktick_merge_tags' for combining tags), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only, idempotent, or destructive, but the description adds useful context about the OAuth process and expected returns. However, it doesn't detail error handling, token expiration, or security implications beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and parameter/return notes in a structured format. Every sentence is necessary and contributes to understanding the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity in handling OAuth authorization, the description covers purpose, usage, and parameters well, and the presence of an output schema means return values don't need explanation. It could slightly improve by mentioning prerequisites or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the parameter's purpose ('Authorization code from callback URL') and its role in the OAuth flow, adding meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Complete OAuth2 authorization') and resource ('with the code from callback URL'), distinguishing it from sibling tools like 'ticktick_configure_oauth' or 'ticktick_login' by focusing on the final authorization step after callback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Use this after visiting the authorization URL and being redirected'), providing clear context for its application in the OAuth flow, which is essential for distinguishing it from other authentication-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which the description doesn't contradict. The description adds valuable context beyond annotations by explaining this is a configuration step that generates an authorization URL, helping the agent understand the tool's behavior in the authentication workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three brief sentences that each serve a distinct purpose: stating the tool's function, explaining its role in the workflow, and outlining inputs/outputs. There's no wasted verbiage, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has annotations covering safety aspects (idempotent, non-destructive), a detailed input schema, and an output schema (implied by 'Returns: Authorization URL and instructions'), the description provides exactly what's needed: context about where this fits in the authentication workflow. No additional explanation of parameters or return values is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only mentions 'params: OAuth credentials' without detailing the specific parameters (client_id, client_secret, redirect_uri). While the schema fully documents these parameters, the description adds minimal value beyond what's in the structured schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Configure OAuth2 credentials') and target resource ('for TickTick API v1'), distinguishing it from sibling tools like ticktick_authorize_oauth which handles the next step in the OAuth flow. It provides a complete picture of the tool's function beyond just the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'This is the first step for OAuth authentication' and mentions 'After configuration, you'll receive an authorization URL to visit,' providing clear context about when to use this tool versus alternatives like ticktick_authorize_oauth. It establishes the tool's role in a multi-step authentication process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds crucial context about irreversibility and cascading deletion of tasks, which goes beyond the annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by a warning in a separate sentence. Every sentence adds critical information with zero waste, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, the description provides essential warnings and scope details. With annotations covering safety aspects and an output schema likely handling return values, the description is complete enough for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not mention the 'project_id' parameter at all. The schema's property description ('Project ID to delete') provides basic semantics, so the baseline score of 3 is appropriate as the description adds no parameter-specific information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a project and all its tasks') with specific verb and resource, and distinguishes it from sibling tools like 'ticktick_archive_project' by emphasizing permanent deletion rather than archiving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns 'This action cannot be undone' and mentions 'All tasks in the project will be deleted,' providing clear guidance on when to use this tool versus alternatives like archiving or updating projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, idempotent, non-destructive operation. The description adds valuable context beyond annotations by specifying the authentication requirement ('Requires v2 API authentication') and the nested structure of tags ('Tags can be nested'), which are not covered by annotations. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only three sentences, each providing essential information: the core purpose, authentication requirement, and tag structure. There is no wasted text, and it is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no input parameters, read-only operation), the description is complete. It covers purpose, authentication, and data structure. With annotations handling safety aspects and an output schema presumably detailing the return format, no additional information is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the parameter is an empty object (no actual input fields). The description does not add parameter details because none are needed, but it implicitly confirms this by not mentioning any parameters. This is appropriate given the schema's simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all tags in your TickTick account'), making the purpose specific and unambiguous. It distinguishes this tool from sibling tools like 'ticktick_create_tag' or 'ticktick_delete_tag' by focusing on retrieval rather than modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('List all tags') and mentions authentication requirements, but it does not explicitly state when not to use it or name specific alternatives. For example, it doesn't differentiate from 'ticktick_get_tag_tasks' which might retrieve tasks associated with tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations by specifying what gets cleared ('authentication tokens') and what the return value is ('Confirmation message'), which helps the agent understand the behavioral impact despite the annotations covering basic safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences: one stating the action and one describing the return. Every word earns its place, and it's front-loaded with the core purpose. No unnecessary information or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, annotations present, output schema exists), the description is complete. It explains what the tool does, what it affects, and what it returns, which is sufficient for an agent to understand and invoke it correctly without needing additional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the action and return value, which adds semantic value where parameters are irrelevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Clear all authentication tokens') and the resource affected ('logout'), distinguishing it from sibling tools like ticktick_login or ticktick_auth_status. It uses precise language that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when authentication tokens need to be cleared), but doesn't explicitly state when to use it versus alternatives like ticktick_auth_status or ticktick_authorize_oauth. It provides clear purpose but lacks explicit comparison or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![TickTick-MCP MCP server](https://glama.ai/mcp/servers/MostafaSuliman/TickTick-MCP/badges/card.svg)](https://glama.ai/mcp/servers/MostafaSuliman/TickTick-MCP)

Score Badge

Copy to your README.md:

[![TickTick-MCP MCP server](https://glama.ai/mcp/servers/MostafaSuliman/TickTick-MCP/badges/score.svg)](https://glama.ai/mcp/servers/MostafaSuliman/TickTick-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MostafaSuliman/TickTick-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server