tick-mcp

by KpihX

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there are many overlapping query tools (e.g., tasks_of_today, week_agenda, week_overview) that could cause confusion despite detailed descriptions.
Naming Consistency5/5
Tool names follow a consistent snake_case verb_noun pattern (e.g., create_task, list_projects), with predictable structure throughout.
Tool Count2/5
71 tools is excessive for the domain; many query variants and verified wrappers are redundant, making the surface feel bloated.
Completeness5/5
Covers all major TickTick features (tasks, projects, habits, tags, sync, stats) with CRUD, batch, and verification actions, leaving few gaps.
Average 3.9/5 across 71 of 71 tools scored. Lowest: 2.7/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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions multi-value filters accept list or string, but omits details about pagination, return format, error handling, or what happens if no items match.
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 short (three lines) and front-loads the purpose. However, it could be better structured with bullet points for clarity, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 28 parameters and no output schema, the description is severely incomplete. It fails to explain what constitutes a 'scheduled item', how the date window works, or the behavior of numerous filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds almost no parameter information beyond a generic note about multi-value filters. All 28 parameters rely solely on the schema, which only provides titles and types.
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 'Query scheduled items inside a date/time window,' specifying the verb (Query), resource (scheduled items), and scope (date/time window). The category label 'Query & Search' and related tools list help distinguish it from siblings.
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 lists related tools (query_tasks, get_all_tasks, get_project_tasks) but does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.
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 all burden. It mentions history types but omits read-only nature, auth details beyond 'Auth: V2', rate limits, or behavior with large result sets.
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?
Description is brief and front-loaded with purpose, includes category and auth tags. One useful note about multi-value filters. Could be slightly more structured but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 36 parameters, no output schema, and no annotations. The description fails to explain return format, pagination, or provide examples, making it severely incomplete for effective 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 coverage is 0%, and the description adds no parameter-specific meaning except that multi-value filters accept list or string. Given 36 parameters, this is insufficient.
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 queries completed, abandoned, or deleted task history, using 'same fine filters'. It names related tools but does not explicitly contrast them, leaving slight ambiguity.
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 history queries and notes multi-value filter behavior, but provides no explicit when-to-use or when-not-to-use guidance versus siblings like get_completed_tasks or query_tasks.
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 discloses the verification and rollback behavior ('rollback hints if verification fails') and includes auth version '[Auth: V2]'. However, no annotations exist, so the description carries full burden. It does not detail side effects, verification criteria, error handling, or whether the wrapper is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence plus tags), but its brevity sacrifices necessary detail. Given the complexity of a batch move with verification, it should be longer but still clear.
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?
The tool lacks output schema and parameter documentation. The description only gives a high-level purpose, omitting details on return values, error states, or verification process. This is insufficient for an agent to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description provides no information about the 'moves' parameter structure, required fields, or format. This is a critical gap for a batch operation tool.
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 identifies the tool as a 'Verified batch move wrapper with rollback hints', specifying both the action (batch move) and the added verification/rollback behavior. It also lists related sibling tools, helping distinguish it from alternatives like 'move_tasks' and 'verified_move_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?
While the description mentions related tools and a '[Category: Verified Actions]' category, it lacks explicit guidance on when to choose this tool over siblings such as 'move_tasks' or 'verified_move_tasks'. It does not specify scenarios where verification is required or contraindicated.
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 must fully disclose behavioral aspects. It only mentions that multi-value filters accept either a list or a single string. It does not disclose authentication requirements (though 'Auth: V1+V2' is noted), rate limits, whether the operation is read-only, or the nature of 'scheduled items'. Significant gaps remain.
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: two sentences and a bracket with metadata. The purpose is front-loaded in the first sentence, and the second sentence adds a key behavior note. No information is repeated or verbose. It earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain what 'scheduled items' are, how results are returned, pagination limits, date formats, or the effect of filters. For such a complex tool, this is completely inadequate.
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 description must compensate but only adds a note about multi-value filter flexibility. Parameter names like 'local_date', 'days', and 'text_query' are somewhat self-explanatory, but many parameters (e.g., 'time_from', 'time_to', 'timed_only') are not described at all. The description adds minimal 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 states the tool returns scheduled items for a multi-day window (default 7 days), which is a clear verb+resource pairing. It also mentions 'Category: Query & Search' and lists related tools, but does not explicitly differentiate itself from siblings like 'tasks_of_today' or 'events_of_today' beyond the window 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 lists three related tools (query_agenda, tasks_of_today, events_of_today) in brackets, implying when to consider alternatives. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it state any prerequisites or context-specific recommendations.
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 must disclose behavioral traits but only mentions multi-value filter acceptance and folder-awareness. It does not cover auth requirements, destructive potential, rate limits, or other behaviors, leaving significant gaps.
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, uses structured tags, and is front-loaded with the core action. It wastes no words, though it could be more precise about parameter behavior.
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?
Given 9 parameters with no schema descriptions, no annotations, and no output schema, the description is incomplete. It lacks details on return values, default behaviors, and edge cases.
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?
The schema coverage is 0%, so the description must compensate. It only addresses multi-value parameters (folder_ids, folder_names, kinds) noting they accept list or string, but ignores other parameters like name_query, regex, include_closed, limit, etc., providing insufficient guidance.
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 states 'Search/filter projects with folder-aware metadata,' which is a specific verb+resource combination. It indicates folder-awareness, distinguishing it from general list tools, but does not explicitly differentiate from all siblings like query_folders.
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 [Related] section lists sibling tools, implying when alternatives might be used, but there is no explicit guidance on when to use this tool vs others, or when not to use it. The note on multi-value filters provides some usage detail.
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 only adds 'Auth: depends on preset query type,' which is a behavioral note. It does not disclose return values, side effects, or other execution details. The description is too sparse for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus metadata), which could be considered too minimal. It includes useful metadata like category and related tools. However, it lacks explanatory detail for the parameters, making it less effective despite its brevity.
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?
Given that there are 2 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the 'limit_override' parameter, what the tool returns, or error conditions. The auth note is helpful but insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning the schema itself provides no parameter explanations. The description adds no meaning about the parameters ('name' and 'limit_override'), failing to compensate for the schema gap. This leaves the agent without understanding parameter semantics.
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 purpose: 'Execute a saved query preset.' It uses a specific verb ('execute') and resource ('saved query preset'). The related tools list distinguishes it from list_query_presets, save_query_preset, and delete_query_preset.
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 related tools and an auth note, providing some context for usage. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is implied but not comprehensive.
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 does not explain what 'verify' entails (e.g., whether it throws errors, reverts changes, or performs checks). The behavior of verification is vague, leaving significant gaps in predictability.
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 very short (one sentence plus metadata in brackets), which is concise and front-loaded. However, it could be more structured to improve readability, e.g., using bullet points for related tools and category.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and zero parameter descriptions, the description fails to provide enough context for an agent to use the tool correctly. Key semantics (e.g., what old_parent_id does, verification behavior) are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters or their meaning. The agent must rely solely on parameter names, which are insufficient for correct 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 action: 'Set or unset a parent relationship, then verify the resulting structure.' It uses a specific verb and resource, and distinguishes itself from siblings by listing related tools like set_subtask_parent, implying a verified variant.
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 lists related tools but does not explicitly state when to use this tool versus the alternatives. Without clear when-to-use or when-not-to-use guidance, the agent must infer context from the 'Verified' category.
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 bears full responsibility for behavioral transparency. It mentions verification but does not explain what happens if verification fails, whether the operation is idempotent, or any side effects. The behavior around the V2 sync verification is left ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main action. The bracket sections for category, auth, and related tools add useful context without being verbose. However, it could be slightly more concise by removing redundant phrasing.
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?
Given the absence of an output schema and low schema coverage, the description is not complete. It fails to specify return values, error handling (e.g., verification failure), or any prerequisites for using the tool. The verification aspect is not elaborated, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters beyond their names. 'project_id' and 'group_id' are mentioned but not defined; notably, 'group_id' likely refers to a folder ID but this is not clarified. The description adds no semantic value over 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 action: assign a project to a folder and verify persistence via V2 sync. It uses specific verbs and resource names, and differentiates from siblings like update_project and list_project_folders.
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 lists related tools (update_project, list_project_folders, full_sync) which hints at alternatives, but it does not explicitly state when to use this tool versus the alternatives, nor does it mention prerequisites or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only mentions 'Auth: none' but does not describe side effects, error handling, or any irreversible consequences of deletion. This is insufficient for a destructive 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 one sentence plus metadata. It is front-loaded and contains no wasted words.
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 simple delete tool, the description lacks parameter explanation, return value, error conditions, and any usage context beyond the action. Without annotations or output schema, this is insufficient 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'name' with 0% description coverage, and the description does not mention it at all. No meaning is added beyond the schema, leaving the agent without guidance on what string to provide.
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' and the resource 'saved query preset', making the purpose unambiguous. It is distinct from sibling tools like list_query_presets, save_query_preset, and run_query_preset.
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 lists related tools but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. The context is clear but lacks exclusions or usage scenarios.
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 full burden. It mentions auth requirements (V1 + V2 when include_project_counts=True), which is helpful. However, it fails to disclose behavioral traits like default behavior (returns folders sorted? pagination? empty results?) or what happens when no parameters are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one main sentence and structured metadata tags (Category, Auth, Related). It is front-loaded with the core purpose. However, it could be slightly more informative without sacrificing conciseness.
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?
Given the tool has 4 parameters, no output schema, and no annotations, the description is too brief. It does not explain the return format, pagination behavior, or how filtering works in detail. The related tools are named but not differentiated in terms of when to use each.
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%, so the description must compensate. It only hints at include_project_counts with 'optional project counts' but does not explain name_query, regex, or limit. The parameter names are somewhat self-explanatory, but the description adds negligible semantic value beyond them.
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 it searches/filters project folders with optional project counts. The verb 'search/filter' and resource 'project folders' are specific, but it could be more precise about the exact filtering capabilities. The related tools list helps distinguish, but not fully.
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?
Related tools are listed (workspace_map, list_project_folders, query_projects), providing some guidance on when to use alternatives. However, no explicit 'when to use' or 'when not to use' directions are given, leaving the agent to infer usage context from sibling names.
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 full burden. It mentions 'grep-like content search' and the auth tags, but does not disclose whether the tool is read-only, or any side effects. The description adds some context but is not comprehensive for a query tool.
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 two sentences plus a structured line for category/auth/related. It is front-loaded and efficient, though it could be slightly improved with bullet points for the related tools hint.
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?
Given the tool's complexity (16 parameters, no output schema), the description is incomplete. It lacks details on return format, pagination, sorting, date filters, and other behaviors, leaving the agent with insufficient context for effective 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%, so the description must compensate. It only notes that multi-value filters accept list/string, which applies to some parameters, but fails to explain the rest of the 16 parameters. This is insufficient for understanding the parameter purposes.
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 'Query notes with folder/project scope and grep-like content search', identifying the tool's function and resource. It also lists related tools, but does not explicitly differentiate from siblings like query_tasks, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage hint about multi-value filters accepting list or string, and lists related tools. However, it lacks explicit guidance on when to use this tool versus alternatives, and does not mention any prerequisites or exclusions.
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 exist, so the description must carry the burden. It notes that multi-value filters accept both a list or single string, which helps. However, it does not disclose other traits like read-only nature, performance, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (3 lines plus metadata) and is front-loaded with the core purpose. It is concise but could be more detailed without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 0% schema coverage, no output schema, and no annotations, the description is severely incomplete. It fails to explain return structure, parameter defaults, or behavior for missing data.
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 description should compensate but only explains that multi-value filters accept a list or single string. It does not clarify other parameters like local_date, days, text_query, or limit_per_section.
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 returns a planning-oriented overview split into events, due tasks, and overdue tasks. This specific verb-resource combination distinguishes it from siblings like week_agenda or upcoming_tasks.
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 mentions related tools in brackets but provides no explicit guidance on when to use this tool versus alternatives. It lacks context on prerequisites or exclusions.
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 carries the full burden for behavioral transparency. It discloses that multi-value filters accept list or string inputs, but does not reveal other important behaviors such as read-only nature, authentication requirements (though [Auth: V1+V2] is hinted), or how 'top items' are determined. This is insufficient for a 7-parameter tool.
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 very concise: one sentence plus metadata in brackets. It is front-loaded with the core purpose. However, it sacrifices detail for brevity, resulting in incomplete guidance. It is appropriately short but could be improved by adding parameter explanations.
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?
Given the tool has 7 parameters with no schema descriptions, no output schema, and no annotations, the description is insufficient. It explains the high-level purpose but omits parameter semantics, output format, and key behavioral details. The tool's complexity demands a more complete description.
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%, so the description must compensate. It only mentions that multi-value filters can be list or string, which is a general note, but it does not explain any of the 7 specific parameters (e.g., project_ids, tags, limit). The description adds minimal meaning beyond the schema structure.
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 summarizes active tasks by priority with top items per bucket. The verb 'summarize' and resource 'active tasks by priority' are specific. It is distinguishable from related tools like query_tasks, tasks_of_today, and overdue_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 description lists related tools (query_tasks, tasks_of_today, overdue_tasks) in brackets, providing context for when this tool might be preferred. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention conditions or prerequisites for using it.
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 provided; the description only mentions 'Auth: none'. It does not disclose behavioral traits like overwrite behavior, side effects, or limitations. With no annotations, the description carries full burden but provides 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with the purpose clearly stated upfront. Related tools are listed efficiently. However, it could be improved by adding more detail without becoming verbose.
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?
Given 4 parameters with no schema descriptions, no output schema, and a write operation, the description is sparse. It does not explain what happens on success/failure, return values, or constraints like naming conventions.
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?
No parameter descriptions in the input schema (0% coverage). The description does not add any meaning or examples for the parameters, leaving the agent to guess their exact expected format or constraints.
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 'Save' and the resource 'query preset', and includes a category and related tools that help distinguish it from siblings.
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?
Related tools are listed, but no explicit guidance on when to use this tool versus alternatives, or any prerequisites. The context is implied but not 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?
No annotations are provided, so the description carries the full burden. It discloses that deletion removes the tag from all tasks, but does not mention irreversibility, authorization requirements, or other side effects beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences covering purpose and behavior, plus bracketed metadata. It is efficient but the structure mixes prose and metadata, which could be more organized.
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 simplicity of the tool (1 required parameter, no output schema), the description adequately covers the core purpose and effect. However, it lacks guidance on usage context and prerequisites, leaving gaps for an AI agent's decision-making.
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?
The description for the only parameter 'tag_name' merely restates 'The tag name to delete' without adding any meaning beyond the schema's title. With 0% schema description coverage, the description fails to compensate by providing format constraints or examples.
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 'Delete a tag. Removes it from all tasks.' This specifies the action (delete) and the resource (tag), and the additional effect. It distinguishes from siblings like 'list_tags' and 'merge_tags' by explicitly mentioning 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'merge_tags' or 'rename_tag'. The description only lists related tools without providing when-to-use or when-not-to-use context.
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 provided, so description carries full burden. It discloses active status and due date constraint, but lacks details on pagination, ordering, or error behavior. Multi-value filter note adds minor 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?
Core purpose is front-loaded in the first sentence. Supporting tags and notes are concise. No redundant information.
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?
With 8 parameters, no output schema, and no annotations, the description is too brief. It omits response format, pagination, and detailed parameter explanations, leaving significant gaps for agent understanding.
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%, so description must compensate. The note on multi-value filters accepting list or string adds value, but individual parameter purposes are not explained. Description does not fully cover parameter semantics.
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 explicitly states it returns active tasks with past due dates, using a specific verb ('return') and resource. It also includes category and related tools to distinguish from siblings like 'tasks_of_today' and 'stale_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?
Lists related tools (tasks_of_today, query_tasks, stale_tasks) which hints at alternatives but does not explicitly state when to use this tool vs others. No when-to-use or 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?
Discloses side effect (automatic update of tasks) and auth requirement (V2) and category. However, no annotations are provided, so the description carries full burden. It lacks details on reversibility, naming constraints, or error conditions.
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?
Very concise, no unnecessary words. The action is front-loaded. The Args section is arguably redundant but not harmful.
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?
Provides key side effect and auth info, but lacks details on return value, error handling, naming rules. With no output schema, more context would be helpful. However, it covers the essential purpose adequately.
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 coverage is 0%, and the description adds minimal parameter information: 'old_name: Current tag name. new_name: New tag name.' This basically replicates the schema titles with slight rewording, not adding significant meaning beyond what a user could infer.
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 'rename a tag' and adds important context 'All tasks using it are updated automatically.' This distinguishes it from related tools like merge_tags and update_tag.
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?
Only lists related tools but provides no guidance on when to use rename_tag versus alternatives like update_tag or merge_tags. There is no 'when not to use' or explicit context.
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 must carry the full burden. It mentions auth and multi-value filter behavior, but fails to disclose other behavioral aspects such as read-only nature, pagination, rate limits, or sorting, leaving significant gaps.
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: three sentences plus tags, with no wasted words. The purpose is front-loaded, and the structure is clean and efficient.
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?
Given 11 parameters, no output schema, and no annotations, the description is far from complete. It does not define 'active tasks', how filters combine, the meaning of 'local upcoming window', or the limit parameter, leaving critical context missing.
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 description must compensate but only adds a general statement about multi-value filters. None of the 11 parameters (e.g., local_date, days, project_ids) are explained, leaving the agent without necessary semantic 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 tool returns active tasks due within a local upcoming window, distinguishing it from siblings like overdue_tasks. It uses a specific verb+resource and mentions the scope, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes auth requirements and that multi-value filters accept list or single string, but lacks explicit guidance on when to use this tool versus alternatives like query_tasks. The related tools list hints but does not provide clear when-not or exclusion criteria.
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 must fully disclose behavioral traits. It mentions auth category (V2) but does not clarify if the operation is read-only, what happens on invalid habit_ids, or any rate limits. The description of after_stamp defaults is helpful but insufficient for full 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 well-structured with a one-line summary, metadata tags, and separated Args/Returns sections. It is concise and front-loaded with the core purpose. Minor redundancy exists between the summary and Args, but overall 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?
For a simple 2-parameter tool with no output schema, the description covers the return format and parameter details adequately. It does not explain error handling or edge cases, but the core functionality is sufficiently documented.
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 coverage is 0%, so the description must compensate. It explains habit_ids as a list of IDs and after_stamp with format YYYYMMDD and the special value 0 for all history, which adds significant meaning beyond the schema's titles. The description also documents the return 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 it retrieves check-in records for habits. The verb 'Get' and resource 'check-in records' are specific. It distinguishes from sibling tools like habit_checkin (check-in action) and list_habits (listing habits), though no explicit differentiation is stated.
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 related tools (list_habits, habit_checkin) implicitly guiding when to use each, but lacks explicit statements about when to use this tool versus alternatives or when not to use it. No exclusion criteria 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?
No annotations are provided, so the description must fully describe behavior. It states that the tool queries active tasks (implying read-only) and mentions multi-value filter flexibility, but does not address authentication details, rate limits, or edge cases like empty results. Some value is added but not comprehensive.
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 two sentences plus a categorized bullet line. It front-loads the key action and capabilities. However, the '[Auth: V1 + V2]' and '[Category: Query & Search]' are cryptic and may not be helpful to an agent without further context.
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?
Given the tool's complexity (33 parameters, no output schema, no annotations), the description is too brief. It does not clarify what 'active tasks' means, the expected date format, how regex works, or sorting behavior. The description leaves significant gaps for such a feature-rich tool.
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 33 parameters and 0% schema description coverage, the description needs to compensate. It only briefly mentions 'fine-grained filters, date/hour ranges' and the multi-value behavior, but does not explain the meaning or format of most parameters (e.g., date formats, priority, tag_mode). This is insufficient for a tool with many parameters.
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 'Query', the resource 'active tasks', and key capabilities: 'fine-grained filters, date/hour ranges, and grep-like matching'. It distinguishes from siblings like get_all_tasks and get_project_tasks by implying this tool offers more advanced querying.
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 lists related tools (query_notes, query_agenda, get_all_tasks, get_project_tasks) but does not provide explicit guidance on when to use this tool versus alternatives. The usage context is implied but not clarified with when-not conditions.
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 provided, the description carries the full burden. It discloses the key behavior of verification after move, but does not detail what happens on verification failure (e.g., rollback, error reporting). More specifics on side effects and error handling 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 a single, clear sentence followed by structured metadata (category, auth, related tools). It is front-loaded with the essential action and contains no redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the description is insufficient for a tool that involves a complex array move specification and a verification process. There is no explanation of how to structure moves, what verification entails, output details, or error handling, which are critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation of the 'moves' parameter, which is an open-ended array of objects with additionalProperties true. The agent receives no guidance on required or optional fields, object structure, or constraints, leaving the parameter effectively undocumented.
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 'Move tasks, then verify that each moved task is present in the destination project,' specifying the verb (move and verify), the resource (tasks), and the unique verification step. This distinguishes it from siblings like 'move_tasks' which likely only moves without verification.
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 includes a 'Category: Verified Actions' and lists related tools ('move_tasks', 'set_subtask_parent'), providing context for when to use this tool (when verification is needed). However, it does not explicitly state when not to use it or provide alternatives, though the category hints at a trade-off in safety vs. speed.
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 bears full responsibility for behavioral disclosure. It only mentions partial auth requirements and does not explain read-only nature, permissions, rate limits, or what happens if the map is empty. The output structure is not described.
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 (two sentences plus metadata tags). The metadata tags provide quick categorization, but the core description could be slightly more structured to include parameter hints. No fluff, but could be improved.
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?
With 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the structure of the map, how filters interact, or what 'active task counts' means. The tool is a complex query tool but the description lacks sufficient detail for full understanding.
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%, yet the description only hints at include_counts ('optionally with active task counts') and ignores other parameters like include_closed, filters, and regex. It adds minimal meaning beyond the schema's field names and defaults.
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 returns a 'navigable map of folders and projects' and notes optional task counts. It distinguishes from siblings like list_projects and list_project_folders by mentioning hierarchical structure, and explicitly lists 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provided category, auth hints, and a list of related tools (list_projects, list_project_folders, full_sync, query_projects), which implies when to use alternatives. However, it does not explicitly state when to prefer workspace_map over siblings or provide clear usage scenarios.
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, description bears full burden. It states it returns active tasks for a day but fails to disclose defaults (e.g., local_date null meaning today), inclusion of subtasks, handling of tasks without due dates, or read-only status. Significant gaps for a query 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?
Extremely concise: three lines for core description plus meta tags. No redundant phrasing. Front-loaded with the primary purpose. Efficiently structured.
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?
Given 8 params, no output schema, and 0% schema coverage, the description omits crucial details like return format, default behavior of local_date, and meaning of 'active' tasks. Leaves many operational questions unanswered.
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 coverage is 0%, yet description only adds that 'Multi-value filters accept either a list or a single string.' No explanation of local_date, text_query, limit, or what 'active tasks' implies. Very little value added beyond schema types.
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?
Description clearly states it returns 'active tasks scheduled for a given local day', specifying verb and resource with a clear constraint (local day). This distinguishes it from siblings like events_of_today (events) and overdue_tasks (overdue 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?
Lists related tools (query_agenda, events_of_today, overdue_tasks) providing context for when to use alternatives. Includes usage note about multi-value filters accepting list or string. However, lacks 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses a verification step ('verify the parent-child relationship afterwards') and includes authentication hints ('Auth: V1 + V2'). This adds behavioral context beyond the schema.
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 very short (two sentences) and includes valuable metadata (Category, Auth, Related) upfront. However, it could be more concise if parameter details were included.
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?
With 16 parameters, no output schema, and no parameter descriptions, the description is incomplete for full understanding. The core action is clear, but users lack guidance on optional fields like content, desc, priority, etc.
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 coverage is 0% (no descriptions in schema), but the description does not explain any of the 16 parameters, even critical ones like parent_id, title, or project_id. The description adds no meaning beyond the schema's field names.
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 'Create a child task and verify the parent-child relationship afterwards' uses a specific verb ('Create') and resource ('child task') and clearly distinguishes from siblings like create_task (general) and set_subtask_parent (which doesn't create).
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 a 'Related' section listing alternatives and a 'Category: Verified Actions' tag, hinting at when to use (for verified subtask creation). However, it does not explicitly state when not to use or compare to alternatives like create_task + set_subtask_parent.
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?
Indicates read-only operation (return items) and auth V1+V2, and notes multi-value filter behavior, but does not disclose rate limits, side effects, or default behaviors for null parameters.
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?
Two sentences plus compact metadata. Front-loaded purpose and key usage hint (multi-value filters). Efficient but could be slightly clearer with parameter grouping.
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 tool with 10 optional parameters, no output schema, and no annotations, the description leaves many gaps: date format, filter semantics, time range interpretation, limit truncation, etc. Incomplete for confident usage.
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 coverage, description adds minimal parameter insight: only a generic note on multi-value filters. No explanation of local_date, project_ids, text_query, time_from, time_to, limit, etc.
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 returns timed scheduled items for a given local day, with category and related tools listed, distinguishing it from siblings like tasks_of_today and query_agenda.
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?
Mentions related tools (tasks_of_today, query_agenda) and that multi-value filters accept list or string, but lacks explicit when-to-use or 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 provided, so description carries the burden. Lists return fields but does not mention that the operation is read-only, safe, or any rate limits or permissions. Basic behavioral disclosure is present but incomplete.
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?
Description is short and front-loaded with the core action and key fields. Tags for category and auth are useful. Could be slightly more structured but is 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?
For a parameterless tool with no output schema, the description provides a reasonable list of return fields. It is adequate for an agent to understand what it returns, though additional behavioral context would improve completeness.
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?
No parameters exist; schema coverage is 100%. Description adds no parameter info because none are needed. Baseline score of 4 is appropriate as there is no missing parameter context.
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?
Description clearly states it retrieves account status with specific fields (inbox ID, Pro subscription, team membership). Related tools are listed but not differentiated, so purpose is clear but sibling distinction is implicit.
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?
Category and auth hints provide context, but no explicit guidance on when to use this versus related tools like get_productivity_stats or full_sync. Usage scenario is implied but not stated.
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 bears full responsibility for behavioral disclosure. It lacks details on atomicity, error handling, permission requirements, or response behavior for a batch mutation tool. The minimal description does not adequately convey behavioral 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 succinct and well-structured: a one-line purpose, metadata tags, and a formatted Args section with examples. Every sentence contributes value without redundancy.
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?
Given the lack of annotations and output schema, the description should cover return values, error scenarios, and behavioral constraints. It only covers input parameters, leaving agents uninformed about what the tool returns or how failures are handled.
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 each parameter's structure (add array of objects with name, update with id and name, delete as IDs) and provides examples. This adds meaning beyond the schema's generic 'additionalProperties: true'.
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, update, or delete project folders in batch,' specifying the verb (batch CRUD) and resource (project folders). It distinguishes from siblings like list_project_folders (read-only) and create_project (single creation).
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 lists related tools (list_project_folders, create_project) and defines three operations with argument formats, but it does not explicitly state when to use this tool vs. alternatives or provide prerequisites beyond '[Auth: V2]'. Usage is implied but not precise.
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 must fully disclose behavior. It mentions the status change and V1 endpoint, but omits details like permissions, side effects (e.g., on subtasks), idempotency, and error scenarios.
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 well-structured. It front-loads the main action, then uses categories, auth, related tools, and parameter descriptions in separate lines. Every sentence serves a purpose without 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?
While the description covers purpose and parameters, it lacks details on return values, error handling, and side effects. Given no output schema and simple parameters, more context on behavioral outcomes would improve 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?
Schema description coverage is 0%, so the description must compensate. It provides brief explanations for each parameter ('project_id: The project containing the task', 'task_id: The task to complete'). These add minimal meaning beyond names but are adequate for simple IDs.
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: 'Mark a task as completed (status → 2)'. It specifies the verb 'complete' and the resource 'task', and distinguishes from siblings by listing related tools like reopen_task.
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 includes a '[Related: reopen_task, get_task_detail, get_completed_tasks]' section, which implicitly guides when to use this tool versus alternatives. However, it lacks explicit when-not or context exclusions.
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 provided. Description adds basic context (category, auth marker) and examples, but does not detail potential side effects or constraints. No contradictions.
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?
Two sentences with category and related tags. Every element is relevant and front-loaded.
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?
Sufficient for a simple list tool with no parameters. Output schema likely covers return values. Could briefly mention output schema, but not 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?
Input schema has no parameters, so baseline is 4. Description adds value with examples of section names, beyond empty 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?
Clearly states the tool lists habit sections with examples (Morning, Afternoon, Evening). Includes category and related tools, but does not explicitly differentiate from siblings like list_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?
Implies usage by mentioning section IDs for organizing habits in create_habit/update_habit, but lacks explicit when-to-use or 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 must cover behavioral traits. It declares the tool is read-only (listing tags) and states the auth category, but does not disclose any side effects, limitations, or data freshness. It could be more transparent about whether it returns all tags or paginated results, though for a list-all tool with zero parameters this is acceptable.
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: two sentences plus a returns list and usage tip. It front-loads the core purpose ('List all tags') and provides only essential meta-information. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (though not shown), the description covers the key return fields and provides related tools and auth info. It could mention whether tags are workspace-specific or system-wide, but overall it is sufficient for an agent to understand and use the tool correctly.
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 no parameters, so schema coverage is 100%. The description does not add parameter semantics because there are none. However, it does add value by explaining the return fields, which helps the agent understand output even though parameters are absent. Baseline 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 'List all tags' (verb+resource) and lists the returned fields: name, label, color, parent, sortOrder. It also distinguishes itself from related CRUD tools for tags via the [Related] section, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives like create_tag or update_tag. It does mention using tag names in create_task/update_task, which hints at a use case, but does not provide clear 'when to use' or 'when not to use' instructions. The related tools list is present but without differentiation.
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?
Description discloses the verification and folder assignment persistence steps, but does not detail failure handling, retries, or what 'verified' means. With no annotations, more context on side effects and limits would be beneficial.
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?
Extremely concise: two sentences plus metadata. Front-loaded with the core purpose, no wasted words.
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?
Covers the main functionality and provides auth and related tool hints. However, missing details on return values, error states, and parameter meanings leave gaps for a tool with 5 parameters and no output schema.
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?
No parameter descriptions in the schema (0% coverage), and the description does not explain any parameter beyond hints from name and context. 'color', 'kind', 'view_mode' remain unclear to agents.
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?
Description clearly states the tool creates a project and then verifies its existence and folder assignment if requested. This distinguishes it from sibling tools like 'create_project' and 'verified_assign_project_folder'.
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?
Provides related tools and auth hints, indicating when to use different auth flows. However, it lacks explicit guidance on when to choose this tool over its siblings e.g., 'create_project' for simpler cases.
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 full burden. It mentions V2 batch but omits important behavioral details such as error handling, atomicity, rate limits, or partial success behavior in a batch delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a short main sentence, a structured metadata line (Category, Auth, Related), and a clear args section. Every sentence adds value without 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?
The description lacks details about return values or error behavior, which is important for a batch operation. With no output schema and no annotations, it leaves gaps despite covering the basic purpose and parameters.
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% coverage and defines tasks as an array with additionalProperties: true, which is vague. The description compensates by specifying the required structure: each item must have 'taskId' and 'projectId', which is essential for correct tool invocation.
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 explicitly states 'Delete multiple tasks at once via V2 batch', which is a specific verb and resource. It distinguishes from sibling tools like delete_task (individual) and batch_create_tasks (creation).
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 lists related tools (delete_task, batch_create_tasks), offering context for alternatives. However, it does not explicitly state when to use this tool vs others or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'permanently,' indicating irreversibility, and notes Auth V2. However, without annotations, it lacks details on side effects or constraints. More could be disclosed for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no superfluous information. It front-loads the action and uses brackets for metadata, making it efficient.
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 one-parameter delete tool, the description covers the essential: permanence, auth, related tools. No output schema needed, and context is 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 description provides a brief arg line for habit_id ('The habit ID to delete'), adding minimal meaning beyond the schema's type and name. It partially compensates but could be richer.
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 'Delete a habit permanently,' which is a specific verb and resource. It distinguishes from sibling tools like update_habit and list_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 lists related tools (list_habits, update_habit) and categorizes under Habits with Auth V2, but does not explicitly state when to use this tool versus alternatives or any 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?
No annotations are provided, so the description bears the full burden. It only mentions pagination parameters but omits behavioral traits like read-only nature, authentication requirements, or side effects. The minimal description does not compensate for missing annotations.
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 a clear purpose line, category/related tags, and an Args section. While brief, every element serves a purpose. The structure is front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (2 optional params, output schema exists), the description covers the core purpose and parameter usage. It lacks details like output format or limitations, but output schema mitigates this. Overall adequate for a straightforward read 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?
With 0% schema description coverage, the description adds meaning by explaining 'start: Pagination offset (default 0)' and 'limit: Max results (default 50)', clarifying their role in pagination beyond schema defaults.
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 deleted tasks from the trash,' specifying the verb and resource. It distinguishes from sibling tools like get_completed_tasks and get_all_tasks by targeting deleted tasks specifically.
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 includes category '[Category: Completed & Trash]' and related tools '[Related: delete_task, get_completed_tasks]', hinting at usage context and alternatives. However, it lacks explicit when-to-use or 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 provided, so the description carries full burden. It correctly indicates a read operation ('list') but does not disclose any potential side effects or behavioral traits beyond the basic listing function.
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?
Concise one-sentence description plus structured metadata and args. Front-loaded with purpose. The args section adds slight redundancy but is acceptable.
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?
Has an output schema (not shown) and one clearly described parameter. The description adequately covers what the tool does and the prerequisite for the project to have kanban view mode. No missing context for a simple listing 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?
With 0% schema description coverage, the description adds meaning by stating 'The project with kanban view mode', clarifying that the project must have kanban columns. This adds value beyond the schema's generic 'string' type.
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?
Clearly states 'List kanban columns for a project', specifying the verb and resource. Distinguishes from siblings like 'manage_columns' which likely does more than listing, and 'get_project_tasks' which focuses on 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?
Provides related tools in metadata but no explicit when-to-use or when-not-to-use. The parameter description implies the project must have kanban view mode, giving a usage condition, but lacks clear alternatives or 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?
No annotations provided, so description carries full burden. It discloses auth requirements (V1+V2), the multi-value filter behavior, and the data domain (active, stale tasks). It lacks details on pagination, sorting, or default limit, but is still 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?
Extremely concise: two sentences plus a compact bracket line encoding category, auth, related tools, and a filter note. Every part adds value and front-loads 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?
While the description captures core purpose and filter behavior, it omits details like return format (fields, structure), default limit, sorting order, and definition of 'active'. For a query tool with no output schema, these would help an agent use the tool effectively.
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 description must compensate. It explains that multi-value filters accept list or string, but does not explain older_than_days or text_query semantics. Parameter names are somewhat self-explanatory, but more detail would improve usability.
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 returns active tasks not modified recently, distinguishing it from sibling tools like query_tasks (general) and overdue_tasks (overdue instead of stale).
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 implicitly suggests use for finding stale tasks via the verb 'return' and the 'active tasks not modified recently' phrase. The related tools are listed but no explicit guidance on when to prefer this tool over alternatives.
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?
Without any annotations, the description must fully disclose behavioral traits. It states the tool updates properties, implying mutation, but omits crucial details: whether unset parameters remain unchanged (likely, given null defaults), auth requirements beyond [Auth: V2], rate limits, or side effects like cascading updates. This lack of depth leaves an agent uncertain about operational boundaries.
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: a single-line purpose, two bracket-enclosed metadata lines, and a bullet-style Args section. Every sentence adds value with no redundancy. Information is front-loaded with the purpose, making it easy for an agent to quickly grasp 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 5 parameters and no output schema, the description adequately explains all inputs but fails to mention the return value (e.g., success indicator or updated tag object). It also does not specify what happens to unset parameters (likely unchanged). For a mutation tool, this is a notable gap, though the tool's simplicity partly compensates. The presence of sibling tools suggests more complex operations exist, but for this specific tool, the description is minimally adequate.
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%, so the description bears full responsibility. It adds meaningful context for all 5 parameters: 'name' is tied to list_tags, 'color' specifies hex format, 'parent' explains how to remove with empty string, 'sort_type' lists valid values, and 'sort_order' is described as numeric. However, it does not clarify default behavior when parameters are omitted (e.g., color unchanged if not provided).
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 'Update an existing tag's properties.' which clearly states the verb (update), resource (tag), and scope (existing). It distinguishes from sibling tools like create_tag, delete_tag, rename_tag, and list_tags, and the related list further helps differentiation.
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 includes [Related: list_tags, create_tag, rename_tag] implying contexts where those alternatives are used, and [Category: Tags] provides context. However, it does not explicitly state when to use this tool versus its siblings or provide exclusions (e.g., 'use this to change color, not to rename'). The prerequisite of obtaining the tag's internal name from list_tags is implied but not directly stated as a usage condition.
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?
No annotations provided, but description adds critical context: irreversible and cascading delete. Auth category noted. Could mention return value or error handling.
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?
Extremely concise: warning, category/auth/related, and args. Every sentence adds value, 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?
For a single-param destructive tool with no output schema, description adequately covers purpose and key behavior. Could mention result type for 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?
Single required parameter project_id. Description minimally clarifies it's the project identifier, but schema has 0% coverage; no format specification (e.g., UUID).
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?
Clearly states verb 'delete', resource 'project', and effect 'all tasks' with strong warning. Distinguishes from sibling tools like list_projects and 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?
Lists related tools but lacks explicit when-to-use vs alternatives. No exclusion criteria among many deletion-oriented sibling tools.
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 highlights that deletion is permanent and irreversible, but no annotations are provided. It does not detail side effects like cascading deletes, error handling, or permission requirements, leaving some behavioral gaps.
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, using just 4 lines including the warning and metadata. It is front-loaded with the core action, and every sentence adds 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 the simple parameters and no output schema, the description adequately covers purpose and inputs. It lacks details on return values or error scenarios, but the task is straightforward.
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 adds meaningful context for both parameters: 'project_id' as 'The project containing the task' and 'task_id' as 'The task to delete.' This compensates for the lack of schema descriptions.
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 'Permanently delete a task' with a strong warning of irreversibility. It distinguishes itself from sibling tools like 'complete_task' and 'get_deleted_tasks' via the 'Related' section.
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 lacks explicit guidance on when to use this tool versus alternatives. While it lists related tools, it does not specify conditions for when delete is appropriate or when to avoid it.
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 full burden. It mentions sync and return fields but does not disclose read-only vs destructive behavior, auth needs, rate limits, or any side effects.
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?
Extremely concise: one key sentence plus metadata line and return fields. No redundant words, front-loaded with action and resource.
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 zero parameters and no output schema, description covers purpose, scope, and return fields. Lacks behavioral context but is adequate for a simple parameterless sync 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?
Input schema has zero parameters, which is the default case. Description does not need to add parameter details; baseline 4 is appropriate as it implies parameterless 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?
Description clearly states the tool performs a full V2 sync of all projects, tasks, tags, and folders in one call. It specifies the resource scope and distinguishes from granular sibling tools like get_all_tasks and list_projects.
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?
Explicitly states 'Best for getting a complete overview of the account' and lists related sibling tools, implying when to use. Does not provide explicit when-not-to-use or alternative selection criteria.
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 exist, so the description carries full burden. It indicates creation but does not disclose potential behaviors like duplicate handling, response format, or side effects. More detail 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 concise and well-structured, with a clear purpose, category, auth note, related tools, and parameter list. 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?
The tool has 4 parameters (1 required) and no output schema. The description covers parameters adequately and provides context via related tools, but lacks information about return values (e.g., created tag object) which would aid agent understanding.
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 descriptions are absent (0% coverage), but the description adds meaningful explanations for all parameters: name as label, color with hex example, parent for hierarchy, sort_type with enumerated values. This compensates well for the schema gap.
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 a new tag' with a specific verb and resource, and the sibling tools like list_tags, update_tag, and delete_tag differentiate it from other 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists related tools (list_tags, update_tag, rename_tag, delete_tag) providing context for when to use this tool. It also notes [Auth: V2] implying authentication requirements, but does not explicitly state when not to use it or provide exclusions.
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 provided, the description carries the full burden. It states the tool performs a read operation (no destructive effects), returns a flat list, and uses V2 sync. It could be more explicit about authentication requirements or whether subtasks are included, but the key behavioral aspects are covered.
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: two sentences plus metadata tags. It front-loads the essential information and contains no extraneous content.
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 covers the tool's purpose, performance benefit, related tools, and return format. The presence of an output schema means return values need not be detailed. It could clarify 'active tasks' scope (e.g., subtasks, shared projects) but overall is adequate for a zero-parameter 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?
The tool has zero parameters, so the description does not need to add parameter information. According to the rubric, baseline for 0 parameters 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 tool retrieves all active tasks across all projects via V2 sync, distinguishing it from per-project tools like get_project_tasks and related sync tools like full_sync.
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 explains the tool is faster than iterating projects individually, providing a clear use case. However, it does not explicitly state when not to use it or mention alternatives beyond the related tools.
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 lists return fields and mentions auth version (V2), but does not disclose whether the data is real-time or cached, nor any side effects. For a read-only stats tool, the description offers basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose, followed by structured metadata lines (category, auth, related, returns). Every sentence is informative and earns its place. No 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 zero parameters and no output schema, the description provides a fairly complete picture by listing all return fields and authentication hint. However, it does not specify the user scope (e.g., 'for the authenticated user') or whether the stats are date-constrained beyond the time periods listed, leaving slight ambiguity.
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 no parameters (0) with 100% coverage, so the description need not explain parameters. It adds value by enumerating return fields, which compensates for the lack of output 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 verb 'Get' and the resource 'productivity statistics', and lists specific return fields (score, level, streaks, completion counts). It distinguishes from sibling tools like get_focus_stats and get_completed_tasks by itemizing the exact outputs.
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 includes a '[Related: ...]' line that lists sibling tools (get_user_status, get_completed_tasks, get_focus_stats), providing context for when to use this tool vs alternatives. It does not explicitly state when not to use it, but the relation hints at differentiation.
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. The description implies a read operation via 'Get full details' but does not disclose side effects, authentication specifics, or what constitutes 'full details.' 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 extremely concise, with a single sentence for purpose followed by metadata and parameter explanation. Every element serves a purpose with no 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?
For a simple tool with one parameter and no output schema, the description is mostly complete. However, it lacks details about the return structure or what 'full details' entails.
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 adds value by explaining that project_id is obtained from list_projects. This provides context beyond the schema's empty type definition.
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 full details of a single project,' using a specific verb and resource. This distinguishes it from sibling tools like list_projects (list) and get_project_tasks (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 mentions related tools and notes that project_id comes from list_projects, implying a typical workflow. However, it does not explicitly state when not to use this tool or provide detailed alternatives.
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 must carry the full burden of behavioral disclosure. It identifies the tool as read-only via '[Category: Tasks — Read]' and lists the data returned, but it does not mention side effects, error handling (e.g., what if the task does not exist), authentication specifics, or rate limits. The description is minimally transparent but lacks depth beyond the basic read nature.
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: one sentence for the primary purpose, a single line for category/auth/related tools, and a compact args list. Every sentence contributes valuable information without redundancy. The structure is front-loaded with the main purpose, and the additional lines are well-organized.
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 is no output schema, the description helpfully enumerates the data returned (checklist, reminders, recurrence, etc.), setting clear expectations. However, it omits details on potential errors (e.g., task not found, permissions) and does not specify whether the response includes all possible fields or only those present. For a simple read operation, it is mostly complete, but a small gap remains.
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%, so the description must compensate. The 'Args:' section provides brief semantic meaning for both parameters: 'The project containing the task' and 'The task ID.' This adds value beyond the schema's bare field names and types, clarifying the role of project_id as a container context. A more detailed format or constraint specification would push it higher, but for two simple string parameters, it's adequate.
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 purpose: 'Return full detail of a specific task' and enumerates the types of information returned (checklist, reminders, recurrence, etc.). It distinguishes from siblings by listing related tools (get_project_tasks, update_task, complete_task) and by explicitly categorizing it as a 'Read' operation, making its role clear among the many sibling tools.
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 context via '[Category: Tasks — Read]' and 'Auth: V1', and mentions related tools, which implicitly guides when to use this tool versus alternatives. However, it lacks explicit statements such as 'Use this when you need full task details; use get_project_tasks for a summary list' or any conditions 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.
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. It mentions 'Auth: none' and implies a read operation, but does not disclose potential pagination, ordering, or limits. For a zero-parameter tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a metadata line, front-loaded with the core purpose. Every part 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 low complexity (no parameters, no output schema), the description adequately covers the tool's action, related tools, and auth requirement. It could hint at the return format, but the simplicity of the operation makes this acceptable.
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 zero parameters with 100% coverage, so the baseline is 4. The description does not need to add parameter info and appropriately focuses on the tool's purpose.
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 'saved reusable query presets', effectively distinguishing it from sibling tools like save_query_preset, run_query_preset, and delete_query_preset.
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 includes a category 'Query & Search' and lists related tools, providing context. However, it lacks explicit when-not-to-use guidance or alternative recommendations beyond naming siblings.
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 full burden. It mentions auto-filling projectId but lacks details on auth, rate limits, or failure behavior. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, concise (few lines), and every sentence provides value. Efficient use of space.
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?
Covers main aspects: batch operation, parameter formats, related tools, and workflow. Lacks output or error handling details, but acceptable for a mutation tool without output schema.
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 coverage is 0%, but description adds examples and auto-fill note for 'add', and clarifies expected structures for update and delete. Significantly aids understanding beyond 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 can create, update, or delete kanban columns in batch, with specific verb and resource. It distinguishes from siblings like list_columns and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a workflow hint and related tools, giving context for when to use. Lacks explicit 'when not to use' but offers sufficient 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 provided, so description carries full burden. It discloses it's a write operation (Category: Tasks — Write) and that it sets status to 0. Lacks details on error conditions, side effects, or prerequisites like task completion status.
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?
Extremely concise: one-line purpose, metadata line, then clean arg list. 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?
For a simple status reset tool, the description adequately covers purpose, parameters, and related tools. No output schema needed. Slightly misses explaining behavior if task is not completed, but overall sufficient.
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%. Description adds brief but clear explanations for both parameters ('The project containing the task', 'The task to reopen'), providing meaning beyond the schema's type and title.
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?
Clearly states 'Reopen a completed task (status → 0)' with a specific verb and resource. Distinguishes from siblings like 'complete_task' and 'update_task' by specifying it targets completed 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?
Mentions related tools (complete_task, update_task) and includes category info, providing context. However, it does not explicitly state when to use versus when not to use, or provide conditions for use.
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?
Describes return value (availability status and list of V2-only feature categories). No annotations provided, so description carries full burden; it sufficiently discloses behavior without side effects.
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?
Description is concise (3 lines) but includes metadata in brackets (category, auth, related) that could be separated. Still, it is front-loaded and each part adds value.
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 parameter-less check tool with no output schema, the description fully covers what the tool does and returns. It is complete and unambiguous.
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?
No parameters in input schema; description does not need to add parameter info. Schema coverage is 100% trivially, so baseline of 4 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?
Description clearly states the tool checks V2 API availability, with the condition of session token configuration. It distinguishes from siblings like ticktick_guide by being specific to V2 availability.
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?
Indicates when to use (to check V2 availability) and mentions prerequisite (session token configured). Includes related tool hint but no explicit when-not-to-use or 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?
No annotations are provided, so the description carries the full burden. It discloses the V2 auth requirement and describes parameter behavior (e.g., default repeat_rule, habit_type options). However, it does not explicitly state the return value or side effects (other than creation). This is adequate but could be improved by mentioning what the tool returns.
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: a brief sentence, followed by metadata (category, auth), related tools, workflow, parameter list, and examples. It is front-loaded with purpose. While slightly verbose (e.g., the Args list repeats schema info), every section adds value, and the examples are helpful. Could be more concise without losing clarity.
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 has 13 parameters, no annotations, and no output schema, the description covers all parameters, provides examples, and suggests a workflow. It is missing explicit return value details and error handling, but for a creation tool, the description is sufficiently complete to guide an agent. The inclusion of related tools and workflow adds necessary 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%, leaving the description to compensate. The description includes a detailed Args section that explains each parameter's purpose, defaults, and constraints in plain language (e.g., habit_type='Boolean' or 'Real', goal as target value, repeat_rule as RRULE). Examples further clarify usage. This adds significant meaning 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 'Create a new habit.' and provides a verb+resource pair. It distinguishes from siblings by listing related tools (list_habits, update_habit, habit_checkin) and suggesting a workflow, showing how this tool fits into a sequence.
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 explicit usage context: a workflow (create_habit → habit_checkin → get_habit_records) and examples for Boolean and Real types. It does not specify when not to use or exclusions, but the guidance is clear enough for an agent to decide when to invoke this tool versus its 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?
With no annotations provided, the description discloses that this is a read operation (Category: Tasks — Read) and mentions authentication (Auth: V1). It also documents the single parameter. However, it does not discuss limits, pagination, or edge cases like empty results.
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, using a single-sentence purpose, a metadata block, and a parameter list. Every part adds value without unnecessary repetition.
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 tool with one parameter and an existing output schema, the description covers the core functionality, parameter meaning, and related tools. It is adequately complete for an agent to use correctly.
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 explains the 'include_completed' parameter with its default value and effect, adding meaning beyond the input schema's type and default. This compensates for the 0% schema description 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 'Return tasks from the TickTick Inbox,' specifying the verb and resource. The inclusion of related sibling tools like get_project_tasks and get_all_tasks helps distinguish it as inbox-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?
The description lists related tools (get_project_tasks, get_all_tasks, create_task), providing context for when to use this versus alternatives. However, it does not explicitly state when not to use it or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return fields (habits with stats) and mentions auth requirement. Since it's a list operation, it implies read-only behavior, though read-only not explicitly stated. Adequate for a simple list.
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?
Description is concise with 4 meaningful lines: purpose, metadata, related tools, and return fields. No excess verbiage; 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 no parameters and output schema present, description covers purpose and return fields. Does not mention pagination or ordering, but for a list with no inputs, it is fairly complete.
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?
Input schema is empty (0 parameters), so baseline is 4 per guidelines. Description adds return field details (id, name, status, etc.), adding value beyond 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?
Description clearly states 'List all habits with stats', specifying verb and resource. Distinguishes from sibling tools like list_habit_sections (lists sections) and get_habit_records (records for a specific habit).
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?
Lists related tools (create_habit, update_habit, habit_checkin, get_habit_records, list_habit_sections) providing context. Does not explicitly state when to use or exclude alternatives, but the category and related list offer implicit 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?
Discloses a critical V1 limitation (groupId is always null) and directs to full_sync() for real values. Lists return fields. Without annotations, the description sufficiently covers behavioral aspects, though it could additionally note if the operation is read-only or if any rate limits apply.
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?
Extremely concise: six lines with clear sections for category, auth, related tools, return fields, usage tip, and a note. Every sentence adds value; 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 zero parameters, presence of output schema (implied by return list), and no annotations, the description is comprehensive. It explains purpose, usage, and a limitation. Could mention ordering or pagination, but not necessary for this 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?
No parameters are defined, so the schema coverage is trivially 100%. The baseline score of 4 applies as per the guidelines; no additional parameter information is needed.
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 'List all TickTick projects (lists)' with a specific verb and resource. It lists returned fields and related tools, making the purpose unambiguous and differentiating it from siblings like get_project_detail or create_project.
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?
Provides explicit guidance on using the returned 'id' as project_id in task tools, and notes a V1 limitation. Mentions related tools, offering context, but does not explicitly state when to prefer this over 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?
With no annotations, the description bears full responsibility. It discloses the behavioral nuance that TickTick ignores parentId on creation, and distinguishes between setting and unsetting a parent. However, it does not mention idempotency, permissions, or potential side effects, which 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 concise and well-structured, using bold, emojis, and sections. Every sentence adds value, and the formatting enhances readability without unnecessary verbosity.
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 has no output schema, so the description should detail return behavior or error conditions. It does not mention what the tool returns (e.g., success message or the updated task), nor does it address prerequisites like task existence. This is a notable gap for a mutation 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?
The input schema has no descriptions (0% coverage), so the description must add meaning. It successfully explains the role of each parameter, including the special constraint that only one of parent_id or old_parent_id should be provided, providing clear semantics 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 sets or unsets a subtask relationship, with a specific verb and resource. It distinguishes itself from related tools like create_subtask by noting that TickTick ignores parentId on creation, clarifying when to use this tool instead.
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 explicit usage guidelines: a workflow (create_task then set_subtask_parent), and instructions for when to provide parent_id vs old_parent_id, including a warning not to provide both. It lacks comparison to sibling tools but is otherwise clear.
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 provided, so description carries full burden. Describes category (Utilities) and auth (none), implying no side effects, but lacks details on output format or error behavior. Adequate for simple 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?
Well-structured: one-line summary, metadata section, parameter explanation, usage note. Every sentence adds value, 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?
For a simple utility with 1 parameter and no output schema, description covers purpose, parameter meaning, and usage guidance. Minor missing detail on exact output format but not critical.
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 has 0% description coverage, but description adds detailed meaning for the only parameter 'minutes_before' with examples. Fully compensates for missing schema descriptions.
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?
Clearly states the verb 'convert' and resource 'minutes into an iCalendar TRIGGER string'. Distinguishes from sibling tools like build_recurrence_rule with a specific purpose.
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 advises when to use this tool (inspection/manual building) versus when to avoid it (use reminder_minutes parameter in create_task/update_task). Provides clear 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosing behavior. It details the V1/V2 workaround for group_id, warns about silent failures, and explains the automatic follow-up call. This is excellent 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 structured with sections (Category, Auth, Related, Workflow, Args) and a detailed warning. While the warning is lengthy, it is necessary. The structure is clear 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 5 undocumented parameters, the description compensates well by explaining the tricky group_id behavior and parameter options. However, it lacks details on return value structure and error conditions, which would make it more complete.
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 adds meaningful information beyond the schema for most parameters: name is required, color is a hex example, kind and view_mode have allowed values listed, and group_id has extensive context about the workaround. A slight improvement would be to note defaults for color and view_mode.
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 a new TickTick project (list).' It specifies the verb (create) and the resource (project), and it distinguishes from sibling tools like list_projects, update_project, delete_project by focusing on creation.
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 a workflow hint ('Create project → manage_columns (for kanban) → create_task') and lists related tools. It does not explicitly state when not to use this tool, but the workflow and warnings about group_id offer sufficient 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?
No annotations provided, so description carries full burden. It discloses date range, status options, limit, and auth, but does not mention ordering or pagination behavior.
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?
Front-loaded with purpose, then additional info in compact format. No wasted sentences.
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?
Output schema exists, so return values are covered. Description addresses core behavior and parameters; could mention pagination but not necessary for a simple retrieval 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 has 0% description coverage; description adds format examples, defaults, and constraints for each parameter, fully compensating for the gap.
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?
Clearly states 'Get completed or abandoned tasks within a date range', specifying verb, resource, and scope. Distinguishes from siblings via 'Related' section.
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?
Provides context via 'Related' list indicating alternatives, but does not explicitly state when not to use this tool. The category and auth info add 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?
No annotations are provided, so the description carries full burden. It explains that it marks a habit as done, describes parameter semantics (e.g., value for Real habits, status defaults), and mentions auth category ([Auth: V2]). It does not disclose potential side effects or rate limits, but the behavior is straightforward.
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: one clear purpose sentence, then meta info and args. It front-loads the purpose and uses bullet-like args without redundancy. Every sentence adds 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 5 parameters (2 required) and no output schema, the description covers all parameters adequately. It does not describe the return value, but for a check-in tool this is likely acceptable. The related tools list adds context. Minor gap for completeness.
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?
With 0% schema description coverage, the description fully compensates. It explains each parameter: habit_id, checkin_stamp (date format YYYYMMDD), value (omit for Boolean, provide number for Real), status (values 0/2 with default), and checkin_time (optional ISO datetime). This adds significant 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 explicitly states it records a habit check-in (mark as done for a specific day). The verb 'Record' and resource 'habit check-in' are specific, and it distinguishes from sibling tools like get_habit_records or create_habit by its action.
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 lists related tools and explains parameters, but does not explicitly state when to use this tool over alternatives like get_habit_records or create_habit. It provides context but lacks direct when-to-use/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.
Behavior4/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 that the tool is read-only (lists all folders) and specifies the return fields (id, name, sortOrder). It also mentions authentication V2 via bracket notation. While no side effects or rate limits are mentioned, the simplicity of the tool makes this sufficient.
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 a few lines containing the main purpose, structured metadata (category, auth, related), return fields, and usage instruction. Every sentence earns its place; there is no wasted text.
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 has no parameters and a simple output structure, the description fully covers purpose, return fields, and usage context. An output schema exists, so return details are further documented externally. The description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%. Per guidelines, baseline is 4. The description adds value beyond the schema by explaining what is returned (id, name, sortOrder) and how to use the output (as group_id in other tools), making the tool's purpose and usage clear.
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 lists all project folders (groups). The verb 'List' and resource 'project folders' are specific, and the addition of '(groups)' clarifies the concept. It distinguishes from siblings like manage_project_folders (which implies CRUD) and list_projects (which lists projects, not folders).
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 explicitly tells agents to use folder IDs as group_id in create/update_project, providing a clear usage context. It also lists related tools for reference. However, it does not explicitly state when not to use this tool or alternative tools, though the sibling names imply distinct purposes.
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 must disclose behaviors. It states that tasks get the target tag and the source is deleted, which are key side effects. It also notes 'Auth: V2' but does not detail idempotency or response behavior, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, then metadata in brackets, then short parameter explanations. Every sentence adds value with 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 tool has no output schema, so the description should mention return behavior (e.g., success indicator). Although the side effects are well covered, the lack of return value information slightly reduces completeness. Given the tool's simplicity, this is a minor gap.
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 description adds crucial meaning beyond the schema's titles: source_name is 'Tag to merge FROM (will be deleted)' and target_name is 'Tag to merge INTO (will remain).' This fully clarifies the role of each parameter.
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: merge one tag into another, with explicit effects (tasks reassigned, source deleted). It distinguishes from siblings like rename_tag and delete_tag by its merge-then-delete behavior.
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 lists related tools (list_tags, rename_tag, delete_tag), offering some contextual guidance. However, it does not explicitly specify when to prefer merge_tags over alternatives, lacking exclusions or use-case triggers.
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?
With no annotations, the description fully discloses the critical behavioral trait of automatically cascading children to avoid orphan subtasks. It explains the internal optimization (O(1) API calls per project) and the returned dict including cascaded_children. This far exceeds basic transparency expectations.
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 clear sections (purpose, warning, cascade explanation, args). It front-loads the main purpose and critical warning. However, it is slightly verbose in explaining the internal mechanics, which could be trimmed without losing 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?
The description thoroughly covers input behavior and the automatic child cascade. However, it does not fully describe the return value beyond mentioning cascaded_children, nor does it specify error handling or rate limits. Given the absence of an output schema, this is a notable 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 schema has 0% description coverage, but the description compensates by detailing the moves argument structure (taskId, fromProjectId, toProjectId) and instructing users to provide only parent tasks. This adds essential meaning beyond the schema's generic object definition.
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 moves tasks between projects via V2 batch, with the specific verb 'move' and resource 'tasks'. It distinguishes itself from siblings like batch_update_tasks by highlighting the automatic child cascade, making its purpose unique.
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 use: when moving parent tasks, as it handles the orphan trap. It lists related tools (batch_update_tasks, list_projects, set_subtask_parent) but lacks explicit when-not-to-use scenarios, though the behavioral warning implies when to prefer this over raw V2.
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 the return format ({'rrule': ...}) and that no authentication is needed (Auth: none). It does not mention any side effects, but for a utility tool that builds a string, this 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 with categories, args list, examples, and return info. Every sentence adds value, and it is concise without being terse.
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 description fully explains the tool's purpose, parameters, return value, and how to use the output. Given the tool's simplicity and the absence of an output schema, it is 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?
Schema description coverage is 0%, so the description must compensate. It does so by listing all 7 parameters with explanations and examples, adding significant meaning beyond the schema titles.
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 builds an iCalendar RRULE string for recurring tasks or habits, which is a specific verb+resource. It distinguishes itself from siblings by mentioning related tools like create_task and update_task, and explains how the output is used.
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 implicitly guides usage by explaining the output is to be passed as the 'recurrence' parameter in create_task/update_task, and includes examples. However, it does not explicitly state when not to use it or alternatives, but given the utility nature, it's 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 carries the full burden. It discloses the two possible output types (heatmap and distribution) with their formats, which adds behavioral transparency. It also mentions auth V2. It doesn't describe side effects or rate limits, but the tool is inherently read-only, making this omission minor.
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: a single sentence introducing purpose, followed by structured Args and Returns sections. Every sentence adds value, and the use of bold headers improves readability without unnecessary length.
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 no output schema, the description provides complete return type structures for both stat_type options. It also includes category, auth requirement, and a related tool. For a simple stats retrieval tool, this covers all necessary 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 and does compensate fully. It explains from_date and to_date with format examples (YYYYMMDD) and specifies that stat_type accepts 'heatmap' or 'distribution', adding meaning beyond the schema's property names and types.
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 focus/pomodoro statistics for a date range.' It specifies the resource (focus/pomodoro statistics) and action (get), and distinguishes from sibling get_productivity_stats by explicitly naming it as a related tool.
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 the tool (retrieving focus stats for a date range) and mentions a related alternative (get_productivity_stats). However, it does not explicitly state when not to use it or provide exclusion criteria, but the context is sufficient for most use cases.
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?
No annotations are provided, so the description bears full burden. It discloses that the tool returns tasks 'with kanban columns if available,' implying conditional output. It also explains the include_completed parameter behavior. However, it does not mention auth details beyond 'Auth: V1' (which is a tag) or error handling. Still, it adds meaningful context beyond a bare read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-line summary, followed by metadata tags and a well-structured Args section. Every sentence adds value; there is no fluff. The format is efficient and easy to scan.
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 has 2 parameters (one required), no enums, and an existing output schema (though not shown). The description covers the essential: what the tool does, how to use parameters, and a notable output detail (kanban columns). It also includes usage guidance and related tools, making it self-contained for an AI agent.
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 context signal claiming 0% schema coverage, the description provides detailed parameter explanations: 'project_id: The project ID (use list_projects to find it).' and 'include_completed: If True, include completed tasks (default: False).' This adds significant meaning beyond the input schema, which only has type and title, no descriptions.
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 purpose: 'Return all tasks from a specific project, with kanban columns if available.' It specifies the resource (tasks of a specific project) and adds detail about kanban columns, effectively distinguishing it from siblings like get_all_tasks (all projects) or get_task_detail (single task).
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 explicit guidance: 'use list_projects to find it' for project_id and lists related tools (list_projects, get_task_detail, get_inbox, list_columns). While it does not explicitly state when not to use this tool versus alternatives like query_tasks, the related tools list implies use cases, and the project-specific nature 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?
No annotations are provided, so the description carries full burden. It discloses the critical behavioral detail that parentId is silently ignored, and notes auto-setting of kind when checklist_items are provided. It states it returns the created task with id. However, it does not discuss error handling, rate limits, or idempotency. Good but not exhaustive.
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 header, prominent warning box, and parameter list. It is relatively long but each section serves a purpose. The warning box is justified given the critical subtask pitfall. Slightly verbose in places (e.g., repeating 'Tags' as array), but overall efficient.
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 (15 parameters, no annotations, no output schema), the description covers all necessary aspects: parameter explanations, a critical behavioral warning, return value, and integration with related tools. It provides a complete mental model for using 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?
Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for all 15 parameters, including types, defaults, and specific values (e.g., priority mapping, reminder_minutes format). Examples are given for dates and tags. This adds significant value 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 starts with 'Create a new TickTick task' which is a clear verb+resource combination. It explicitly distinguishes from related tools like update_task and complete_task, and provides workflow context for subtasks. 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit when-to-use guidance (task creation) and a prominent warning about the subtask trap, advising to use set_subtask_parent instead. It also mentions batch_create_tasks for batch operations, and categorizes the tool under 'Tasks — Write'. This makes selection vs siblings 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?
With no annotations provided, the description carries full responsibility. It discloses critical behavioral details: group_id uses V2 internally with a read-modify-write pattern to avoid wiping other fields, and V1 responses return groupId=null, requiring full_sync() for verification. These are beyond basic input schema expectations.
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-organized with a clear purpose sentence, parameter list, and two warning blocks. It is somewhat lengthy due to the warnings, but every sentence adds value. The structure front-loads the core action, then details parameters and caveats. Minor redundancy in the parameter list could be tightened.
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 7 parameters, no output schema, and no annotations, the description is remarkably complete. It covers all parameter behaviors, side effects (group_id internal V2 logic), verification needs (full_sync), and auth differences (V1 vs V2). No critical gaps are apparent for an agent to invoke the 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?
Schema description coverage is 0%, so the description fully compensates. It explains every parameter with concrete examples (color: Hex color, kind: 'TASK' or 'NOTE', view_mode: 'list', 'kanban', or 'timeline'). It also adds behavioral semantics for group_id (read-modify-write) and closed (archive/unarchive). This far exceeds minimal parameter info.
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?
Clearly states 'Update an existing project' with the verb 'update' and resource 'project'. The phrase 'Only provided fields are changed' distinguishes it from create/delete operations. Sibling tools like create_project and delete_project are explicitly listed in the Related section, aiding differentiation.
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?
Includes a [Related] list with direct alternatives (get_project_detail, create_project, etc.) and mentions auth requirements. However, it does not explicitly state when to prefer this tool over siblings (e.g., when to use update_project vs batch_update_tasks). The implicit guidance is clear but lacks explicit 'when-to-use' or 'when-not-to-use' language.
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?
Discloses limitations of V2 batch for reminders, explains silent rejection and dueDate invisibility, and states response format. No annotations provided, so description carries full burden.
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?
Well-structured with sections and warnings, but slightly lengthy. All content is relevant; 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, parameters, caveats, alternatives, and response format comprehensively for a batch update 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 has 0% description coverage and param is untyped. Description adds critical detail: each task dict must include 'id' and 'projectId', full field values required, no read-modify-write.
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?
Clearly states 'Update multiple tasks at once via V2 batch' and includes 'Category: Tasks — Batch' and 'Related: update_task, batch_create_tasks, batch_delete_tasks'. Distinguishes from siblings.
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 warns not to use for reminder updates, explains why, and directs to preferred pattern using update_task(). Also mentions read-modify-write caveat.
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 of behavioral disclosure. It thoroughly describes the tool's behavior, including parameter behavior (partial match, case-insensitive, default null), and includes a detailed 'AGENT OPERATING CONTRACT' that covers silent failure patterns, verification discipline, and proactive user feedback. There is no contradiction with any annotations.
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 verbose due to the 'AGENT OPERATING CONTRACT' section, but it is well-structured with headers, examples, and a tip. Every sentence provides value, though the contract could be separated into a system-level instruction. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool ecosystem and the lack of output schema, the description is exceptionally complete. It covers all usage modes, parameter details, filter ergonomics, and a comprehensive contract for safe multi-step operations. The agent has all necessary context to use this tool effectively.
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 description adds significant meaning beyond the input schema. It explains each parameter's purpose, gives examples for category and intent, mentions case-insensitive partial matching for category, and explains the boolean show_workflows. This fully compensates for the 0% schema description 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 it is an 'Interactive guide to all TickTick MCP tools — START HERE.' It explains exactly what the tool does: calling with no args lists categories, with a category lists tools, with an intent shows recommended tool paths, and with show_workflows shows multi-step patterns. This distinguishes it clearly from sibling 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?
The description provides explicit guidance on when to use this tool: 'START HERE,' call with no args, category, intent, or show_workflows. It mentions a related tool (check_v2_availability) and offers examples for each parameter. Additionally, the 'AGENT OPERATING CONTRACT' gives extensive usage rules for the entire agent workflow.
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?
With no annotations, the description fully discloses behavioral traits: it explains the read-modify-write pattern for safe partial updates, warns that the V2 batch endpoint does full replacement, and specifies that only provided fields are changed. This is comprehensive and honest.
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 structured well with sections: general description, args list, critical warning, and common uses. It is somewhat lengthy but each sentence adds value due to the tool's complexity. Front-loaded with the key behavior.
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 12 parameters, no output schema, and no annotations, the description covers all necessary aspects: behavior, parameters, usage warnings, common scenarios, and related tools. It is thorough and leaves no major gaps.
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 0% schema description coverage, the description lists all 12 parameters with meaningful explanations, including examples for reminders (e.g., format and clearing) and status values (0=active, 2=archived). It adds substantial context beyond the schema's property names.
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 an existing habit' with a specific verb and resource. It distinguishes from siblings by explicitly mentioning it's a partial update (read-modify-write) and contrasting with create_habit and delete_habit in the 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?
The description provides explicit usage context: when to use for partial updates, common examples like archive/rename/reminders, and a critical warning against using the underlying batch endpoint directly. It also lists related tools for context.
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?
Despite no annotations, the description fully discloses behavioral traits: read-modify-write (safe for partial updates), reminder anchor dependency, silent failure when due_date is null, and the need to pass unchanged fields for correct reminder computation. The V1/V2 gotcha is explained in detail.
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 long but well-structured with clear sections (Args, Category, Auth, Related). The gotcha is verbose but necessary. It front-loads the main action and then details parameters. Minor improvement: could be slightly more compact.
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 18 parameters, no output schema, and no annotations, the description covers all necessary context: parameter behaviors, usage constraints, gotchas, and examples. It provides everything an agent needs to invoke the 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?
With 0% schema description coverage, the description compensates completely. Every parameter (priority values, date clearing, tag replacement, status codes, recurrence, etc.) is explained. The reminder_minutes parameter includes critical usage context and an example.
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 explicitly states 'Update any fields of an existing task', clearly identifies the resource and action. It distinguishes from siblings like create_task, complete_task, reopen_task through the 'Related' section and the main verb 'update'.
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 provides explicit when-to-use guidance by referencing related tools (get_task_detail, create_task, etc.) and includes a detailed gotcha about reminders requiring due_date+time_zone. It gives an example and conditions for correct usage.
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?
Discloses a critical behavioral trap: parentId is silently ignored. Also describes return format and the need to check id2error. Since no annotations are provided, this description fully covers behavioral 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?
Well-structured with sections, warnings, and a clear Args/Returns breakdown. Every sentence is purposeful, no wasted words. 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?
For a single-parameter tool with no output schema, the description covers input requirements, output format, error handling, and the critical subtask trap. No gaps remain.
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 has 0% coverage (only 'tasks' as array of objects with additionalProperties: true). The description adds essential meaning: required 'title', optional fields, and explicitly warns against including parentId. This fully compensates for the minimal 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 'Create multiple tasks at once via V2 batch', with a specific verb and resource. It distinguishes from sibling tools like create_task, batch_update_tasks, and batch_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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use this tool vs alternatives, including a warning not to pass parentId and to use set_subtask_parent instead. Lists related tools for context.
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:

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

Score Badge

Copy to your README.md:

[![tick-mcp MCP server](https://glama.ai/mcp/servers/KpihX/tick-mcp/badges/score.svg)](https://glama.ai/mcp/servers/KpihX/tick-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/KpihX/tick-mcp'

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