ticktick-mcp-enhanced

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource and action: projects, tasks, subtasks, habits, and authentication all have clear boundaries. Even similar-sounding tools like get_all_projects and get_project_info differ in scope, and query_tasks vs get_completed_tasks are clearly separated. No two tools overlap in a way that would cause an agent to select the wrong one.
Naming Consistency4/5
The vast majority of tools follow the predictable verb_noun pattern (create_project, update_tasks, get_habit, delete_projects, checkin_habits). The only outliers are 'ticktick_status' and 'login', which are not verb_noun, but they are minor deviations and do not create confusion.
Tool Count4/5
At 21 tools, the server is on the heavier side but still well-scoped for a feature-rich TickTick integration covering projects, tasks, and habits. Each tool serves a distinct purpose, and the count is appropriate for the breadth of functionality offered.
Completeness4/5
The tool surface provides comprehensive coverage for projects and tasks, including create, read, update, delete, and specialized operations like moving tasks and querying. The only notable gap is the absence of a habit deletion tool, which is a minor missing CRUD operation that agents could work around.
Average 4.3/5 across 20 of 21 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It only states 'Create a new project,' implying a mutation but omitting any side effects, authentication requirements, or failure conditions such as duplicate project names. This is minimal 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 compact and to the point: one purpose sentence followed by a short Args list. No redundant or filler text is present.
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 simple create operation with three parameters and an output schema, the description covers the essential purpose and all parameter nuances. It falls slightly short in explaining when to choose this over related project tools, but is otherwise adequate for invocation.
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 Args descriptions add clear value beyond the schema: color is specified as a hex format, and view_mode enumerates its allowed values (list, kanban, or timeline). This fully compensates for the schema's 0% property description coverage, though the name parameter is only trivially described.
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 opens with a specific verb and resource ('Create a new project in TickTick'), clearly identifying what the tool does. It differentiates from sibling tools like create_tasks and update_projects by specifying 'new project'.
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?
No guidance is provided on when to use this tool versus updating or deleting projects. There are no alternative tool references or exclusion conditions, so the agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only covers the input format. It does not disclose side effects, permission requirements, reversibility, or response behavior. The mutation is implied by 'complete' but no additional behavioral context is given.
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 well-structured: a one-line summary, a usage note, and a formatted Args section with examples. Every sentence adds value, and the examples make the structure instantly understandable. No 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?
The description thoroughly documents the one parameter and its required subfields, and an output schema exists (though not shown) so return values don't need to be explained. It lacks details on preconditions or error cases, but for a simple completion tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is generic (an object or array of string maps), providing zero coverage of the required fields. The description compensates fully by specifying that each task must contain project_id and task_id, and by showing concrete examples for both single and batch cases.
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 'Mark one or more tasks as complete' with a specific verb and resource. It also highlights batch support, but does not explicitly distinguish from sibling tools like update_tasks or ticktick_status, so it stops short of a 5.
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 explains how to pass single vs. multiple tasks (dictionary vs. list) and provides examples, giving clear usage context. However, it does not mention when to prefer this tool over alternatives or any exclusions, making the guidance 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Delete' which implies destructiveness, but it does not disclose whether deletion is permanent, reversible, or requires special permissions. It also does not mention any side effects or partial failure behavior in batch deletion. The description adds no behavioral context beyond the tool's name.
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 well-structured with a brief overview, a bullet explaining the parameter format, and examples. The 'Args' section slightly duplicates schema information but the examples add value. It is concise without unnecessary filler, though it could be tightened by removing the explicit 'Args' repetition.
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?
The tool is relatively simple with one parameter, and an output schema exists (though not shown), so return values need not be described. However, given the lack of annotations and the destructive nature, the description would benefit from stating permanence or irreversible effects, and clarifying behavior for partial batch failures. It covers input well but misses important operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains the 'projects' parameter, stating it can be a string or a list of strings, and provides clear examples for both single and multiple project IDs. This goes beyond the schema's basic type definition and gives practical usage guidance.
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 begins with 'Delete one or more projects', which is a specific verb (delete) and resource (projects). It clearly distinguishes from sibling tools like delete_tasks by naming the resource. The additional detail about supporting both single and batch deletion further clarifies the 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 clear guidance on how to pass arguments (single ID vs list) but does not explicitly state when to use this tool versus alternatives. It does not mention exclusions or alternative tools like delete_tasks. The context for using this tool is implied by its name rather than explicitly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the input format but does not state whether deletion is permanent, how missing tasks are handled, or whether batch deletion is atomic. This is a significant gap for a destructive mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose, clear mode explanation, explicit args with required fields, and illustrative examples. Every sentence adds value, and there is no unnecessary verbosity.
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?
The tool is simple, and the description thoroughly covers input requirements for both single and batch deletion. While it lacks details on return values or error behavior, the presence of an output schema likely covers that. Overall, it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is very generic (anyOf object/array with additionalProperties), providing no field-level detail. The description compensates by explicitly requiring project_id and task_id, clarifying single vs list inputs, and providing concrete examples. This makes parameter usage unambiguous.
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 opens with 'Delete one or more tasks,' clearly identifying the verb and resource. It also distinguishes itself from sibling tools like update_tasks or complete_tasks by explicitly focusing on deletion and supporting batch 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 usage is implied: if you want to delete tasks, use this tool. However, there is no explicit guidance on when to prefer this over alternative tools (e.g., for completing tasks) or any exclusions. The description does not mention alternatives like delete_projects or complete_tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does not mention side effects, reversibility, required permissions, or any limitations, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the purpose statement. It includes a concise parameter breakdown and necessary examples, with no redundant or wordy content—every sentence earns its place.
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?
The description thoroughly covers the input structure for a complex single-parameter tool, and the existence of an output schema means return-value documentation is not needed. It does not address error conditions or prerequisites, but overall it is fairly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a generic 'moves' object/array with additionalProperties true, so the description is essential. It explicitly defines the required fields (from_project_id, to_project_id, task_id) and includes clear examples for both single and multiple moves, adding substantial meaning beyond the 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 it moves one or more tasks from their current project to a different project. This uses a specific verb-and-resource structure and distinguishes it from siblings like update_tasks or delete_tasks.
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 usage is implied by the tool's name and description, but there is no explicit guidance on when to choose this tool over alternatives like update_tasks or complete_tasks, nor any mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states that habits are created, without mentioning side effects, validation behavior, error handling, or required authentication. 'Create' implies mutation but lacks depth about what happens on failures or partial batch successes.
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?
Although longer than a terse description, every sentence earns its place by documenting fields and providing examples. The structure with 'Args' list and separate examples is well-organized and front-loaded with a clear summary. No fluff.
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 minimal schema and no annotations, the description thoroughly covers all parameter semantics and examples for both single and batch creation. It is complete enough for an agent to understand how to invoke the tool correctly. The presence of an output schema means return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a generic 'habits' field with no structure, while the description compensates fully by listing required and optional fields, types, formats (e.g., hex color, RRULE), and defaults. The examples further clarify correct usage, making the parameter meaning explicit.
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 'Create one or more habits in TickTick,' identifying the specific verb (create) and resource (habits). It distinguishes itself from sibling tools like create_tasks and create_project by the resource and the explicit batch creation capability.
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 gives clear context on how to use the tool: supports both single dict and list for batch creation, with examples. It does not explicitly mention when not to use it or contrast with alternatives, but the usage pattern is unambiguous.
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?
No annotations are provided, so the description carries the full burden. It documents required and optional fields, input formats, and batch behavior, but it does not disclose whether updates are partial (only provided fields are changed) or full replacement of the task object. Also, it lacks details on error handling, idempotency, or side effects. This is a significant behavioral ambiguity for an update operation.
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 lengthy but well-structured with an Args list and examples. Every sentence serves a purpose; the length is justified by the complexity of the task parameters. It is front-loaded with the purpose and clearly organized, though it could be slightly more concise by trimming redundant wording.
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 (many optional fields, batch support, timezone handling) and minimal schema, the description covers most necessary information. However, the partial vs. full update ambiguity is a gap that affects complete understanding. An output schema exists, so return-value documentation is not required, but the update semantics should have been clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is extremely generic (a single 'tasks' property with anyOf object/array and additionalProperties true), providing essentially zero parameter documentation. The description compensates fully by listing all required and optional fields, their types, formats (ISO datetime, IANA timezone), and even an example. This is high-value semantic clarification.
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 it updates existing tasks, with specific verb+resource and scope ('one or more existing tasks'). It distinguishes itself from sibling tools like create_tasks, delete_tasks, and move_tasks by focusing on modification of existing tasks.
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 clearly implies when to use this tool (updating existing tasks) and provides usage examples for both single and batch updates. However, it does not explicitly mention alternatives or exclusions (e.g., use create_tasks for new tasks, move_tasks for moving between projects). It gives clear context without explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses the core action (get) and the parameter, but doesn't mention what happens if the habit isn't found (e.g., error vs null) or any other behavior. For such a simple getter, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose, the argument definition, and a usage example. Every sentence earns its place, and the example aids comprehension.
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 (one parameter, no nested objects), the description fully covers the necessary context: what it does, how to call it, and a sample. The presence of an output schema means return values don't need to be detailed here.
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 coverage, the description compensates by explicitly naming 'habit_id: ID of the habit' and providing an example with 'habit-1'. This adds meaning beyond the schema's property name, though it's minimal.
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 'Get a single habit by its ID,' using a specific verb and resource. It distinguishes itself from siblings like get_all_habits (plural) and get_habit_checkins by focusing on a single habit by ID.
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 when to use (when you have a specific habit ID and need that habit) and provides a concrete example. It doesn't explicitly mention alternatives, but the context is clear and excludes other operations like listing or checkins.
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?
With no annotations, the description carries the burden of behavioral disclosure. It does explain input structure and validation constraints (e.g., project_id must match), but it doesn't mention side effects, return values, error handling, or permissions. Basic mutation is implied but not stated. This is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with an intro, ARGS section, and examples. Every sentence adds value; no filler. The format is scannable and the examples clarify the structured data needed. Length is justified by the need to document a flexible schema.
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 sparse schema and the tool's role in creating subtasks, the description is highly complete. It covers all necessary input details, constraints, and multiple usage scenarios. An output schema exists, so return-value documentation is unnecessary. The info provided is sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema is minimal (just a generic 'subtasks' object/array). The description fully compensates by listing every subfield with required/optional status, priority enum values, and case-insensitivity. It also provides concrete examples for single and multiple subtasks, making invocation straightforward.
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 uses a specific verb and resource: 'Create one or more subtasks for parent tasks.' This clearly distinguishes it from sibling tools like create_tasks by specifying the parent relationship. No ambiguity.
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?
While it doesn't explicitly state alternatives or exclusions, the description clearly implies when to use this tool (when creating subtasks under an existing parent task). The detailed parameter requirements (parent_task_id, project_id) provide context for usage, but it lacks direct statements about when not to use it.
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?
With no annotations to lean on, the description carries the full burden and discloses defaults ('date defaults to today'), internal conversion ('converted to the API's YYYYMMDD stamp'), and value/goal semantics. It doesn't discuss auth or side effects, but for a create/update tool the behavioral details provided are substantial.
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 well-structured with a clear summary, field notes, and labeled examples. It is somewhat long, but every sentence adds necessary detail given the flexible schema. The front-loaded purpose sentence makes it easy to grasp immediately.
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?
The tool's complexity lies in its open-structured checkins parameter, and the description fully covers that complexity: field semantics, defaults, formats, batch usage, and examples. An output schema exists, so return values need not be explained. The description is complete for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and an open 'additionalProperties' structure, so the description must compensate. It does so thoroughly by defining each field (habit_id required, date optional with format, value default 1.0, goal default 1.0, status optional) and providing concrete examples for boolean, numeric, backfill, and batch cases.
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 opens with a specific verb+resource: 'Create or update a habit check-in (mark a habit as done for a given day).' This clearly distinguishes it from sibling tools like get_habit_checkins (reading) and create_habits/update_habits (managing habits themselves).
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 rich usage context: it explains single vs batch usage, defaults, boolean vs numeric habit examples, and backfilling with a past date. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to apply it correctly.
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?
With no annotations provided, the description carries the burden of transparency. It states that it returns complete habit objects including IDs and explicitly notes that there are no parameters, which sets expectations. It does not explicitly state that it is read-only, but the verb 'List' strongly implies a non-mutating operation. The example call adds transparency about invocation.
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 very concise: three short sentences plus an example. The purpose is front-loaded in the first sentence, and every sentence adds value—return content, usage hint, and invocation example. No fluff or redundant information.
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?
For a simple list-all tool with zero parameters and an output schema present, the description fully covers what the tool does, what it returns, and how to invoke it. It includes an example and suggests a practical follow-up action. There are no obvious gaps in context.
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?
There are zero parameters, and the schema coverage is 100% (vacuously). The description explicitly says 'No parameters' and provides an example invocation, which is more than sufficient for a parameterless tool. Per the rubric, the baseline for 0 params is 4, and it is met.
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 opens with a clear verb and resource: 'List all of the user's habits.' This distinguishes it from the sibling get_habit (which likely retrieves a single habit) by emphasizing 'all'. The purpose is unambiguous and specific.
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?
It provides usage context by stating that the returned habit objects (with IDs) enable direct follow-up actions like creating a check-in. It implies when to use this tool (when you need the full list), though it does not explicitly name alternatives or exclusions. This is clear context without being exhaustive.
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?
Without annotations, the description carries the full burden. It discloses the return type (formatted string), the special 'inbox' value, and that all tasks are included. It does not explicitly state read-only, but 'Get' and 'view' imply no mutation. Additional error-handling details would improve 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 well-structured with a concise summary, a brief expansion, and clearly labeled Args/Returns/Examples. Each section earns its place without unnecessary 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 simplicity (one parameter) and lack of annotations, the description covers the essential aspects: input, output format, and special behavior. It could be more complete by stating read-only status or error handling, but it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by explaining the project_id parameter (ID or 'inbox') and providing concrete examples, adding meaning far 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 tool gets comprehensive information about a single project, including both project metadata and all tasks. This distinguishes it from siblings like get_all_projects (which lists projects) and query_tasks (which searches tasks), as it provides a combined single-project view.
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 use when a complete view of one project is needed ('complete view of a project in one call'), but it does not explicitly mention alternatives or when not to use it. It provides clear context and examples, but lacks explicit exclusions.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently explains the tool returns status fields (configured, authenticated, ready) and is non-mutating in nature ('Check', 'Returns'). It does not mention side effects, but for a status check this is not a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action, and every word adds value. No filler or repetition.
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?
For a simple status tool with no parameters and an output schema present, the description completely captures the essential information. It conveys the tool's purpose and the nature of its return value without needing to detail output fields.
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 zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 for zero-parameter tools 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 uses a specific verb ('Check') and a clear resource ('current connection status with TickTick'), immediately distinguishing it from sibling tools like create_project or login. It clearly states what the tool does and what it reports.
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 as a health/readiness check by stating it returns whether the server is configured, authenticated, and ready to use. It does not explicitly name alternatives or when-not-to-use, but for a status tool the intended context is clear.
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?
With no annotations provided, the description discloses the partial-update behavior (only provided fields change), support for single or multiple habits, and the requirement for habit_id. It doesn't cover error handling or atomicity, but the core behavioral traits are transparent.
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 well-structured and efficient: a one-line purpose, a brief behavior note, a compact field list, and two illustrative examples. There is no redundancy, and the format makes scanning easy.
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?
Despite the complex nested parameter, the description thoroughly explains the parameter structure, required fields, and behavior. It's missing explicit error handling or return value information, but the presence of an output schema and the detailed usage notes make it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is completely opaque—just a generic object/array with no field descriptions. The description compensates by specifying the required habit_id, listing all optional fields with types, and providing clear examples. This gives full semantic meaning beyond the 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 tool's function: 'Update one or more existing habits in place.' It specifies the verb, resource, and scope, distinguishing it from sibling tools like create_habits by emphasizing 'existing' and 'in place.' This 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 use for modifying existing habits, reinforced by examples showing single and batch updates. It doesn't explicitly name alternatives or state when not to use it, but the context and sibling tool names make the intended use clear.
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?
With no annotations, the description takes on the burden of behavioral disclosure. It reveals that the tool returns complete task objects so no second lookup is needed, that date bounds are inclusive, and that datetimes must include timezone offsets. It could go further on edge cases like no results, but it is solidly transparent.
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 well-organized with an intro, Args block, and Examples. Every sentence earns its place—optionality, return value, parameter meanings, and examples are all covered without 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?
Despite having an output schema, the description still adds valuable context about return value (complete objects) so the agent knows it can act directly. Parameter semantics are thorough, examples illustrate both filtered and unfiltered calls, and the tool's behavior is fully specified for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must and does provide full semantics for all three parameters. It explains project_ids accepts "inbox", start_date/end_date are ISO with timezone offsets and inclusive lower/upper bounds, and gives concrete examples that clarify usage.
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 the resource "completed tasks" within a project and time-range scope. This distinguishes it from sibling tools like query_tasks (which likely lists all tasks) and complete_tasks (which marks tasks complete).
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?
It provides clear context for when to use the tool (for completed tasks) and gives parameter guidance (at least one recommended to narrow results). However, it does not explicitly mention alternatives or exclude use cases, e.g., saying "use query_tasks for non-completed tasks."
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?
With no annotations, the description carries the full burden. It discloses that the tool returns complete check-in objects for the given date range, and the example clarifies input expectations. It does not mention edge cases like date inclusivity or empty results, but for a read-only retrieval tool the disclosure is adequate.
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 well-structured: a clear one-sentence purpose, a brief benefit statement, labeled arguments, and a concrete example. Every line adds value with no redundant or filler content.
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, the existing output schema, and no annotations, the description covers all necessary aspects: what it does, how to specify parameters, and a practical use case. No major gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having 0% description coverage, the description fully explains all three parameters: habit_ids accepts a single ID or list, from_date is a YYYYMMDD integer, and to_date is a YYYYMMDD integer. The example further reinforces the format and usage.
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 uses a specific verb ('Get') and resource ('habit check-in records') with an explicit date-range scope. It clearly distinguishes itself from siblings like checkin_habits (which writes check-ins) and get_habit/get_all_habits (which fetch habit definitions).
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 use cases: analyzing streaks, completion rates, and finding missed days without a second lookup. It does not explicitly name alternatives or when-not-to-use conditions, but the context strongly implies when this tool is appropriate.
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?
With no annotations, the description carries the full burden and does well: it discloses that a browser window opens, the tool blocks, and it can time out after 120 seconds. It also warns against inventing URLs. Minor omission: no explicit mention of what happens on success or failure beyond timeout, but the output schema 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 well-structured with an opening summary, helpful URLs, a clear Args list, and a behavioral note. Every sentence contributes practical value; no filler 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?
The tool is an interactive OAuth flow with four parameters and no annotations. The description covers purpose, credential sourcing, parameter defaults, user prompting, browser behavior, and timeout handling. Combined with the output schema, this is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully compensates: it explains each parameter's meaning, required status, default values, where to find them, and even provides conditional usage guidance (e.g., 'Use the default unless the user explicitly says...'). This is exemplary parameter 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 opens with a specific verb+resource: 'Log in to TickTick by providing OAuth credentials.' This clearly distinguishes login from the operational sibling tools (project/task/habit management) and states the exact purpose.
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?
It explicitly instructs to 'Ask the user for all four parameters' and provides concrete decision rules for optional parameters (e.g., use default unless user explicitly states otherwise). It does not mention when not to use the tool, but login is a prerequisite for all other tools, making the usage context clear.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the key non-obvious behavior that Inbox is not included and points to the proper way to retrieve inbox data. It doesn't mention return format or auth, but that is less critical for a simple read-only tool with an 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 concise and front-loaded. It states the primary function in one sentence, then adds a focused note about the Inbox exception and alternative tool. Every sentence earns its place.
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 (no parameters, output schema present), the description is complete. It clearly scopes what is returned and directs the agent to the sibling tool for the special case, making it sufficient for correct selection and invocation.
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 zero parameters, so the schema fully covers parameter semantics. The description appropriately adds no redundant parameter information, and baseline for 0 params is 4.
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 'Get' and the resource 'all projects from TickTick', and explicitly notes the Inbox exclusion, which distinguishes it from get_project_info and other project-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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool (for all projects) and provides a direct alternative for the excluded case: use get_project_info(project_id='inbox'). This is clear usage guidance.
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?
No annotations are provided, so the description carries the full burden. It discloses critical behaviors: the need for time_zone, the meaning of omitting due_date (all-day), the exact format for reminders (TRIGGER strings with examples), and the fact that no alarm fires without reminders. These go beyond what the schema shows.
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?
Though detailed, the description is well-organized with an opening summary, an Args list with bullet points, and two practical examples. Every clause adds value, and the most critical info (title, project_id, time_zone, reminders) is front-loaded in the Args list.
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?
For a complex tool with a single loosely-typed parameter, the description is remarkably complete: it covers all inner fields, formats, edge cases (all-day vs timed tasks), and provides examples. An output schema is present, so return values need not be described. Minor omissions like the structure of 'items' are acceptable since subtask creation is handled by a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the schema only defines 'tasks' as an object or array. The description compensates fully by listing every inner field (title, project_id, content, desc, start_date, due_date, time_zone, priority, repeat_flag, items, reminders) with types, formats, defaults, and examples. This is exceptional compensation.
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 starts with 'Create one or more tasks in TickTick', which is a specific verb + resource + scope. It clearly distinguishes from sibling tools like update_tasks or delete_tasks by stating creation and batch support.
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?
It explicitly explains when to use single vs batch creation ('For single task, you can pass a dictionary directly. For multiple tasks, pass a list of dictionaries.') and provides important usage warnings (e.g., 'Without this, NO alarm fires'). However, it does not explicitly mention alternative tools like update_tasks for modifications, but for a creation tool the usage context is clear.
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?
No annotations are provided, so the description carries the full burden. It fully discloses behavior: all parameters optional, when no filters returns all tasks, AND logic when combining filters, special behavior for task_id with and without project_id, and the meaning of date_filter values. It also notes case-insensitivity for priority and search_term. This is thorough and transparent.
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 well-structured with a clear opening, logical parameter breakdown, and a helpful examples section. Although lengthy, every part adds value—parameter details and examples are essential for a flexible tool with 6 parameters. It is organized and front-loaded with the core purpose.
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 complexity (6 optional parameters, no enums), the description is complete. It covers all parameters, behaviors, combinations, and provides examples. Since an output schema exists, the lack of return value explanation is acceptable. The description leaves no ambiguity about how to invoke the tool for common scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only basic parameter names and types with no descriptions (coverage 0%). The description compensates by explaining every parameter in detail, including valid values, constraints (e.g., custom_days requires date_filter='custom'), and semantics like 'inbox' for project_id. Examples further clarify usage. This far exceeds the schema's 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 it is a 'Unified task query tool' with 'flexible multi-dimensional filtering,' which is specific and distinguishes it from sibling tools like get_completed_tasks or get_all_habits. It explains exactly what it does: query tasks with various filters, and includes multiple examples.
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 extensive usage context, stating all parameters are optional, that filters combine with AND logic, and includes seven concrete examples showing various use cases. However, it does not explicitly mention when to use this tool versus alternatives like get_completed_tasks for completed tasks, so it lacks explicit exclusions but gives clear context.
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?
With no annotations, the description carries the full burden. It discloses in-place, non-destructive updates, partial update behavior, and support for batching via list. It does not mention error handling or permissions, but covers core behavioral traits well.
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 well-structured: a concise purpose sentence, a usage guideline, clearly labeled Args with bullet-like formatting, and two illustrative examples. Every sentence contributes useful information with no 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?
Covers purpose, usage, full parameter detail, and examples. An output schema exists, so return values are presumably already documented. It lacks error-condition details, but for a batch update tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is bare (0% description coverage), so the description fully documents the 'projects' parameter: required project_id, optional name, color, view_mode, and kind, including enum values and an example hex code. This adds substantial meaning beyond the 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 'Update one or more existing projects in place (without deleting them)', using a specific verb and resource. It distinguishes itself from siblings like create_project and delete_projects by emphasizing the 'in place' and 'without deleting' aspects.
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?
Explicitly recommends 'Use this instead of delete-then-recreate to avoid losing the tasks inside a project', providing a clear alternative and rationale. Also explains partial update semantics ('Only the fields you provide are changed; omitted fields keep their current value'), which guides correct usage.
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-enhanced MCP server](https://glama.ai/mcp/servers/Code-MonkeyZhang/ticktick-mcp-enhanced/badges/card.svg)](https://glama.ai/mcp/servers/Code-MonkeyZhang/ticktick-mcp-enhanced)

Score Badge

Copy to your README.md:

[![ticktick-mcp-enhanced MCP server](https://glama.ai/mcp/servers/Code-MonkeyZhang/ticktick-mcp-enhanced/badges/score.svg)](https://glama.ai/mcp/servers/Code-MonkeyZhang/ticktick-mcp-enhanced)

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/Code-MonkeyZhang/ticktick-mcp-enhanced'

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