TickTick MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools cover distinct aspects of TickTick's functionality (tasks, projects, habits, focus, calendar, analytics), but there is significant overlap within categories, such as multiple analytics tools (e.g., get_productivity_insights, get_productivity_report, get_monthly_insights) and multiple focus-related tools (e.g., start_focus_session, pause_focus_session, get_focus_stats), which could cause confusion for an agent. Descriptions help differentiate, but the sheer number of similar tools increases ambiguity.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a 'ticktick_' prefix and a verb_noun structure (e.g., ticktick_create_task, ticktick_get_projects). This uniformity makes the tool set predictable and easy to parse, with no deviations in naming conventions across all 114 tools.
Tool Count2/5
With 114 tools, the count is excessively high for a task management server, leading to potential overwhelm and inefficiency. While TickTick has broad features, many tools could be consolidated (e.g., multiple analytics or focus tools), making the surface feel bloated and difficult to navigate for an agent.
Completeness5/5
The tool set provides comprehensive coverage of TickTick's domain, including CRUD operations for tasks, projects, habits, and tags, along with advanced features like analytics, focus sessions, calendar integration, and team collaboration. There are no obvious gaps; all major workflows and lifecycle stages are supported, ensuring agents can handle a wide range of user requests without dead ends.
Average 2.7/5 across 114 of 114 tools scored. Lowest: 1.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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It does not indicate whether this is a read-only or destructive operation, what permissions are required, how errors are handled, or any rate limits. The term 'mass assignment' implies a write operation, but without annotations, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with only two words, the description is under-specified rather than efficiently structured. It fails to front-load critical information and does not earn its place by adding value beyond the tool name, making it ineffective despite its brevity.
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?
For a tool with no annotations, no output schema, and a description that lacks behavioral and usage details, the description is incomplete. It does not compensate for the missing structured data, leaving the agent with insufficient information to understand the tool's operation, especially given its potential for bulk mutations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters ('assignments' and 'notify_assignees'). The description adds no additional meaning beyond what the schema provides, such as explaining the structure of assignments or the implications of notifications. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mass task assignment' is a tautology that essentially restates the tool name 'ticktick_bulk_assign_tasks' without adding meaningful specificity. It mentions the action ('assignment') and resource ('tasks') but lacks detail about what 'mass' or 'bulk' entails compared to the sibling tool 'ticktick_assign_task', leaving the purpose vague and undifferentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the sibling tool 'ticktick_assign_task' for single assignments, nor does it specify prerequisites, constraints, or appropriate contexts for bulk operations, offering no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read or write operation, what permissions are required, whether it's destructive, what happens during synchronization, or any rate limits. The description fails to provide any behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise at just two words, this represents under-specification rather than effective conciseness. The description doesn't provide enough information to be useful, and the single phrase doesn't earn its place by adding value. Good conciseness balances brevity with information density, which this description lacks.
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?
For a synchronization tool with 3 parameters and no annotations or output schema, the description is completely inadequate. It doesn't explain what gets synchronized (tasks, events, calendars?), how the synchronization works, what the expected outcomes are, or any behavioral characteristics. The description fails to provide the minimal context needed for an agent to understand and use this 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?
The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Outlook integration' is a tautology that restates the tool name 'ticktick_sync_with_outlook' without specifying what the tool actually does. It doesn't mention the verb 'sync' or clarify what resources are being synchronized between TickTick and Outlook. While the name suggests synchronization, the description fails to articulate the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when synchronization is appropriate, or how this differs from the sibling tool 'ticktick_sync_with_google_calendar'. The agent receives no contextual information about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate whether this is a read or write operation (though 'create' implies mutation), what permissions might be required, whether it's idempotent, what happens on failure, or what the output looks like. For a tool that creates tasks from templates, this lack of behavioral information is a significant gap that could lead to incorrect agent usage.
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?
While the description is technically concise with just two words, this represents under-specification rather than effective brevity. The description fails to convey essential information about what the tool does, making it inefficient despite its short length. It doesn't follow the principle of front-loading critical information or earning its place through meaningful content.
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 4 parameters (including a nested object), no annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'instantiating' a template means in practical terms, what the resulting task looks like, what happens with the customizations, or how the create_multiple parameter works. The description fails to provide the contextual information needed to understand this tool's operation and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters well-documented in the input schema itself. The description adds no additional parameter information beyond what's already in the structured schema fields. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Instantiate template' is a tautology that essentially restates the tool name 'ticktick_create_task_from_template'. While it implies creating something from a template, it doesn't specify what resource is being created (tasks), what system it's in (TickTick), or how it differs from similar tools like 'ticktick_create_task' or 'ticktick_bulk_create_from_template'. The purpose is vague and lacks the specificity needed for clear agent understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing an existing template, when to choose this over 'ticktick_create_task' for standard task creation, or how it relates to 'ticktick_bulk_create_from_template' for multiple instances. There's no context about appropriate use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it only states 'Team performance reports,' which does not reveal whether this tool performs a read-only operation, requires specific permissions, has side effects (e.g., generating files), or involves rate limits. This lack of transparency is critical for a tool with potential data export functionality.
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?
While the description is brief ('Team performance reports'), this brevity results in under-specification rather than effective conciseness. It lacks front-loaded critical information (e.g., the action 'export') and does not structure details to aid understanding. A single vague phrase fails to earn its place by adding value beyond the tool name.
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 (4 parameters, nested objects, no output schema) and lack of annotations, the description is incomplete. It does not explain what the tool returns (e.g., a file or data), behavioral aspects, or how it integrates with sibling tools. For a report generation tool, this gap leaves the agent without sufficient context to use it 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?
The input schema has 100% description coverage, clearly documenting all four parameters (project_id, report_type, date_range, format) with enums and defaults. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or usage examples. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Team performance reports' is vague and tautological—it essentially restates the tool name 'ticktick_export_team_report' without specifying the action (e.g., 'generate' or 'export') or clarifying the resource scope. It fails to distinguish this tool from sibling tools like 'ticktick_export_analytics_data' or 'ticktick_get_team_activity', leaving the purpose unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, such as how it differs from other export or report-related tools in the sibling list. This absence of usage instructions makes it difficult for an agent to select this tool appropriately.
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 of behavioral disclosure. It vaguely hints at 'various options' but fails to specify that this is a destructive operation (implied by parameters like 'confirmation_code'), lacks details on permissions required, rate limits, or what 'reset' entails (e.g., data deletion vs. restoration). The description does not compensate for the absence of annotations, leaving key behavioral traits unclear.
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 single sentence 'Reset or manage user data with various options' is overly brief and under-specified, not concise. It fails to front-load critical information (e.g., destructive nature) and wastes space on vague phrasing ('various options') that adds no value. A more structured approach with clear intent and warnings would improve utility without sacrificing 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 the tool's complexity (destructive operations, 5 parameters) and lack of annotations or output schema, the description is incomplete. It does not address the tool's impact (e.g., data loss), success/failure responses, or error conditions. For a high-stakes tool like data reset, the description should provide more context to guide safe and effective use, which it currently fails to do.
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 100%, so the schema fully documents all 5 parameters (e.g., 'reset_type' enum values, 'backup_before_reset' default). The description adds no additional meaning beyond the schema—it does not explain parameter interactions (e.g., 'data_categories' only applies to 'partial-data') or provide usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reset or manage user data with various options' is vague and tautological—it essentially restates the tool name 'ticktick_reset_user_data' without specifying what 'reset' or 'manage' entails. It lacks a clear verb-resource combination (e.g., 'delete user tasks' or 'restore default settings') and does not distinguish this destructive operation from sibling tools like data export or update functions, which are non-destructive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., user confirmation), exclusions (e.g., irreversible actions), or related tools (e.g., 'ticktick_export_analytics_data' for backup). This omission is critical for a tool with destructive potential, leaving the agent without context for safe invocation.
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 full burden for behavioral disclosure. 'Modify template' implies a mutation operation but reveals nothing about permissions required, whether changes are destructive, what happens to existing template data not mentioned in parameters, or what the response looks like. This is inadequate for a mutation tool with 5 parameters.
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?
While technically concise with just two words, this represents under-specification rather than effective brevity. The description fails to front-load essential information and doesn't earn its place with meaningful content.
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 mutation tool with 5 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what 'modify' entails, what happens to unspecified template fields, or what the tool returns. The context signals indicate significant complexity that the description fails to address.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds zero additional parameter information beyond what's in the schema, meeting the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Modify template' is a tautology that restates the tool name 'ticktick_update_task_template' without adding meaningful specificity. It lacks a clear verb-resource combination and doesn't distinguish this template modification tool from sibling tools like 'ticktick_update_task' or 'ticktick_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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparison to sibling tools like 'ticktick_create_task_template' or 'ticktick_delete_task_template'.
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. 'Google Calendar sync' implies a potentially destructive or mutating operation that could modify calendar data, but it doesn't disclose any behavioral traits such as what gets created/updated/deleted, authentication requirements, rate limits, or side effects. The description is too vague to inform the agent about the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Google Calendar sync'), which could be seen as efficient, but it's under-specified rather than appropriately sized. It consists of just two words that don't provide meaningful guidance, so it fails to earn its place as a helpful description. It's front-loaded by default due to its brevity, but lacks substance.
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 complexity of a sync operation (which involves data transfer and potential mutations), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how conflicts are handled, or any operational details. The schema covers parameters well, but the description fails to provide necessary context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters clearly documented in the input schema (google_calendar_id, sync_direction, date_range_days). The description adds no additional meaning or context about the parameters beyond what the schema already provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Google Calendar sync' is a tautology that essentially restates the tool name 'ticktick_sync_with_google_calendar'. It mentions the resource (Google Calendar) but lacks a specific verb or action beyond 'sync', which is already implied in the name. It doesn't distinguish this from sibling tools like 'ticktick_sync_with_outlook' beyond naming the different calendar service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing Google Calendar access), when sync is appropriate, or how it differs from other sync or import/export tools in the sibling list like 'ticktick_bulk_calendar_import' or 'ticktick_sync_with_outlook'.
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 of behavioral disclosure. 'Create reusable template' implies a write/mutation operation but provides no information about permissions required, whether templates are private or shared by default, what happens on creation failure, or any rate limits. The description is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words. While this could be seen as under-specified rather than truly concise, it does efficiently communicate the core action without unnecessary words. However, it lacks the front-loaded completeness that would earn a perfect score.
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 mutation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'reusable template' means in practice, what happens after creation, how templates are used, or any behavioral aspects. The agent would struggle to understand the full context of this tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create reusable template' is a tautology that essentially restates the tool name 'ticktick_create_task_template'. While it indicates the action (create) and resource (template), it lacks specificity about what kind of template (task template) and doesn't differentiate from sibling tools like 'ticktick_create_task_from_template' or 'ticktick_get_task_templates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to create a template versus creating a task directly, when to use this versus 'ticktick_create_task_from_template', or any prerequisites or context for template creation. This leaves the agent with no usage 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 carries full burden. 'Remove attachments' implies a destructive mutation, but it doesn't disclose whether this is permanent, requires specific permissions, has side effects (e.g., affecting task history), or provides confirmation. For a deletion tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with no wasted verbiage. However, this brevity comes at the cost of under-specification—it's too minimal to be fully helpful. It's front-loaded but lacks necessary detail, making it efficient but incomplete.
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 (a destructive deletion operation), lack of annotations, and no output schema, the description is incomplete. It fails to address key contextual aspects like what happens after deletion (e.g., success response, error handling), whether deletions are reversible, or how it interacts with other tools. For a mutation tool, this minimal description is inadequate.
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 100%, with both parameters (task_id and attachment_id) clearly documented in the schema. The description adds no parameter-specific information beyond what the schema provides. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove attachments' is a tautology that essentially restates the tool name 'ticktick_delete_task_attachment'. While it indicates the action (remove) and resource (attachments), it doesn't specify that these are task attachments or differentiate from sibling tools like 'ticktick_delete_task_note' or 'ticktick_delete_task' that also delete task-related items. The purpose is vague about scope and specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., attachments must exist), when-not-to-use scenarios (e.g., if you want to download instead), or comparisons to siblings like 'ticktick_get_task_attachments' (for viewing) or 'ticktick_upload_task_attachment' (for adding). Usage is entirely implied from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Remove template' without behavioral details. It doesn't disclose if this is destructive (likely permanent deletion), requires specific permissions, has side effects (e.g., affecting tasks created from the template), or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two words, which is efficient and front-loaded. However, it's under-specified rather than appropriately sized—it lacks necessary detail for a deletion tool. It earns a 4 for brevity but loses points for missing essential 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 (a destructive deletion operation), lack of annotations, and no output schema, the description is incomplete. It fails to explain behavioral traits, usage context, or return values, leaving significant gaps for an AI agent to understand and invoke 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?
Schema description coverage is 100% (the 'template_id' parameter is fully described in the schema), so the baseline is 3. The description adds no parameter information beyond what the schema provides, but it doesn't need to compensate for gaps. No credit is given for repeating schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove template' restates the tool name 'ticktick_delete_task_template' without adding specificity. It doesn't clarify what type of template (task template) or what 'remove' entails (permanent deletion vs archiving). While it distinguishes from siblings like 'ticktick_create_task_template' by implying deletion, it lacks the verb+resource clarity needed for higher scores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing template ID), exclusions, or related tools like 'ticktick_update_task_template' for modifications. The description offers no context for decision-making.
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 'AI-powered' but doesn't disclose behavioral traits like whether this is a read-only operation, requires specific permissions, has rate limits, or what the output format might be. The description is too minimal to inform the agent about how the tool behaves beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase 'Get AI-powered productivity insights'. It is front-loaded and wastes no words, making it easy to parse quickly. Every word serves a purpose in conveying the core function.
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 complexity implied by 'AI-powered insights' and the lack of annotations and output schema, the description is incomplete. It doesn't explain what insights are returned, their format, or any behavioral context. For a tool that likely provides analytical data, more detail is needed to help the agent understand what to expect from the invocation.
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 1 parameter with 100% description coverage, providing details on the 'period' parameter. The tool description adds no additional parameter semantics beyond what the schema already documents. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get AI-powered productivity insights' states a general action but lacks specificity about what insights are provided or what resource is accessed. It doesn't distinguish from siblings like 'ticktick_get_productivity_report' or 'ticktick_get_monthly_insights' which seem similar. The description is vague about the actual content or format of the insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools that appear related (e.g., 'ticktick_get_productivity_report', 'ticktick_get_monthly_insights', 'ticktick_get_completion_trends'), the description offers no context about differences, prerequisites, or appropriate scenarios for selecting this specific insight tool.
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 of behavioral disclosure. 'Detect scheduling conflicts' implies a read-only analysis operation, but it doesn't specify what constitutes a conflict (e.g., overlapping events/tasks), how results are returned, whether it's real-time or cached, or any rate limits or authentication requirements. For a tool with no annotation coverage, this leaves significant 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 extremely concise with just two words, 'Detect scheduling conflicts', which is front-loaded and wastes no space. While it may be under-specified, it earns full marks for conciseness as every word directly relates to the tool's function without unnecessary elaboration.
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 (conflict detection with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of conflicts, boolean result), how conflicts are defined, or provide context beyond the bare minimum. For a tool with no structured behavioral data, this description fails to compensate adequately.
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 100% description coverage, with all parameters well-documented in the schema itself (e.g., start_date, end_date, include_tasks, conflict_threshold_minutes). The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between parameters or typical use cases. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Detect scheduling conflicts' is a tautology that essentially restates the tool name 'ticktick_get_schedule_conflicts'. It lacks a specific verb-resource combination and doesn't distinguish this tool from potential siblings like 'ticktick_get_calendar_events' or 'ticktick_get_today_tasks' that might also involve scheduling. The purpose is vague about what exactly is being detected and how.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to tasks, calendars, and scheduling (e.g., 'ticktick_get_calendar_events', 'ticktick_get_today_tasks', 'ticktick_filter_tasks'), there's no indication of when this conflict detection is appropriate versus other query tools. No context, exclusions, 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.
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 of behavioral disclosure. 'Configure access levels' implies a mutation/write operation, but it doesn't disclose important behavioral aspects: whether this requires admin permissions, whether changes are reversible, what happens when applied to existing collaborators, or what the response looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's 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?
The description is extremely concise at just two words. While this represents under-specification in terms of content, from a pure conciseness perspective, it's maximally efficient with zero wasted words. Every word in 'Configure access levels' serves a purpose, even if that purpose is inadequately fulfilled.
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 mutation tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'configure' entails, what happens when permissions are changed, whether there are side effects, or what the tool returns. The agent would need to guess about important behavioral aspects of this permission-setting operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configure access levels' is a vague purpose statement that doesn't specify what resource is being configured or what action is performed. It doesn't mention projects (the main parameter) or distinguish this from other permission-related tools like 'ticktick_invite_collaborator' or 'ticktick_remove_collaborator' in the sibling list. While it hints at permission management, it lacks the specificity needed for clear tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to project management and collaboration (e.g., 'ticktick_invite_collaborator', 'ticktick_share_project'), but the description offers no context about when this specific permission configuration tool is appropriate versus those other options.
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. 'Export project data' implies a read-only operation, but it doesn't disclose behavioral traits such as whether it requires specific permissions, what the output looks like (e.g., file download, structured data), rate limits, or side effects. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, 'Export project data', which is front-loaded and wastes no space. Every word contributes to the core purpose, making it efficient though under-specified.
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 no annotations, no output schema, and a vague description, this is incomplete for a tool with 3 parameters. The description doesn't compensate for the lack of structured data, failing to explain what 'project data' entails, the output format, or usage context. It's inadequate for guiding an agent 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 100%, so the schema fully documents the three parameters (project_id, format, include_completed). The description adds no additional meaning beyond what the schema provides, such as explaining the scope of 'project data' or format details. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export project data' states a basic purpose but is vague. It specifies the verb 'export' and resource 'project data', but doesn't clarify what 'project data' includes (tasks, metadata, structure) or how it differs from other export tools like 'ticktick_export_analytics_data' or 'ticktick_export_habit_data'. It's better than a tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'ticktick_export_analytics_data' and 'ticktick_export_habit_data', the description doesn't indicate this is for general project data export, nor does it mention prerequisites or exclusions. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'team communication' and implies a write operation ('Add'), but fails to disclose critical behavioral traits: whether this requires specific permissions, if comments are editable/deletable, rate limits, or how mentions work. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. No unnecessary verbiage, but brevity comes at the cost of completeness.
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 no annotations, no output schema, and a mutation tool with team collaboration aspects, the description is incomplete. It lacks details on permissions, behavioral constraints, return values, and differentiation from siblings. For a 4-parameter tool in a crowded sibling set, this minimal description is inadequate.
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 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying 'team communication' (which relates to 'mention_users' and 'is_private'), but doesn't explain parameter interactions or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add comment for team communication' states the action (add) and resource (comment), but it's vague about scope and context. It doesn't specify this is for tasks (though implied by name) or differentiate from sibling tools like 'ticktick_add_task_note' or 'ticktick_update_task_note', leaving ambiguity about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'ticktick_add_task_note' and 'ticktick_update_task_note', the description lacks context on distinctions (e.g., comments vs. notes, team vs. private communication), offering no explicit when/when-not or alternative 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?
No annotations are provided, so the description carries full burden. It mentions 'bulk operations' but doesn't disclose behavioral traits like whether this is a mutation (likely yes, given 'add', 'remove', 'replace'), potential side effects (e.g., affecting multiple tasks), error handling, or rate limits. The description is minimal and fails to add meaningful 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 a single sentence, 'Perform bulk operations on tags', which is concise and front-loaded. However, it's overly brief and under-specified for a tool with 4 parameters and no annotations, missing opportunities to add value without verbosity. It earns points for brevity but loses some for lacking substance.
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 (bulk mutations with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, leaving significant gaps. The schema covers parameters well, but the description fails to compensate for missing context on operations and effects.
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 100%, with all parameters well-documented in the schema (e.g., 'operation' with enum values, 'task_ids' as array of IDs). The description adds no additional meaning beyond what the schema provides, such as explaining how 'replace' works or constraints on tag names. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform bulk operations on tags' states the general purpose but is vague. It specifies the resource ('tags') and hints at bulk capability, but lacks a clear verb beyond 'operations' and doesn't distinguish from sibling tools like 'ticktick_add_tag_to_task' or 'ticktick_remove_tag_from_task' that handle single-task tagging. It's adequate but leaves ambiguity about what 'operations' entail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, such as needing existing tags or tasks, or compare it to sibling tools like 'ticktick_add_tag_to_task' for single operations. Usage is implied only through the name and schema, with no explicit context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Transform' suggests a mutation, but the description doesn't specify what happens to the original task (e.g., is it deleted, archived, or modified?), what permissions are required, or what the output looks like. It lacks details on side effects, error conditions, or rate limits, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Transform task into calendar event') that is front-loaded and wastes no words. It could be slightly more informative, but it's appropriately sized for a simple tool, with no redundant or verbose 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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the transformation process, what the result looks like, or potential impacts on the original task. For a tool that modifies data, more context is needed to ensure safe and correct usage, making this inadequate.
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 100% description coverage, with clear parameter definitions (e.g., task_id, event_duration_minutes). The description adds no additional meaning beyond the schema, such as explaining how parameters interact (e.g., if start_time is omitted) or providing examples. Since the schema is comprehensive, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transform task into calendar event' clearly states the action (transform) and target (task to calendar event), but it's vague about the specifics of the transformation. It doesn't distinguish this tool from sibling tools like 'ticktick_create_calendar_event' or 'ticktick_update_task', which could involve similar calendar-related operations. The purpose is understandable but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the task must exist), exclusions (e.g., tasks already converted), or compare it to siblings like 'ticktick_create_calendar_event' for creating events from scratch. Usage is implied from the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. 'Create calendar event' implies a write/mutation operation, but the description doesn't mention authentication requirements, whether the event is immediately published, what happens on conflicts, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, which is appropriate for a simple tool. However, it's arguably too brief given the lack of other context. The structure is front-loaded with the core action, but could benefit from additional context given the complexity of the tool ecosystem.
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 mutation tool with no annotations, no output schema, and a rich ecosystem of sibling tools, the description is incomplete. It doesn't explain what distinguishes calendar events from tasks, doesn't provide behavioral context for the creation operation, and doesn't guide usage relative to alternatives. The agent would need to infer too much from the minimal description.
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 100%, so all parameters are documented in the schema. The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create calendar event' states the basic action (create) and resource (calendar event), but it's vague about what specifically distinguishes this from other creation tools like 'ticktick_create_task' or 'ticktick_convert_task_to_event'. It doesn't specify that this creates events in the calendar rather than tasks, which is a key distinction given the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for creating tasks, habits, and projects, there's no indication that this is specifically for calendar events rather than other types of items. No prerequisites, exclusions, or complementary tools are mentioned.
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 full burden but offers minimal behavioral insight. It states 'Create' implying a write/mutation operation, but doesn't disclose permissions required, whether it's idempotent, rate limits, or what happens on failure (e.g., if template_id is invalid). It lacks context on the creation process, such as whether it copies all template tasks or settings.
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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. The brevity is a strength, but it borders on under-specification given the tool's complexity.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the creation outcome (e.g., returns project ID, error handling), behavioral traits, or usage context. Given the complexity (3 parameters, write operation), more detail is needed to guide an agent 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 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain template_id format, project_name constraints, or implications of customize_tasks). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create project from a template' clearly states the action (create) and resource (project), but it's vague about scope and doesn't distinguish from sibling tools like 'ticktick_create_project' (creates from scratch) or 'ticktick_bulk_create_from_template' (bulk operation). It lacks specificity about what 'from a template' entails beyond the basic verb-noun pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing template), exclusions, or compare it to siblings like 'ticktick_create_project' (for non-template creation) or 'ticktick_create_task_from_template' (for tasks instead of projects). Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states 'Export' but does not reveal if this is a read-only operation, requires authentication, involves rate limits, or what the output entails (e.g., file download, data stream). This leaves critical behavioral traits unspecified for a tool that likely accesses user data.
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 a single, efficient phrase with no wasted words, making it front-loaded and easy to parse. However, it is overly terse, bordering on under-specified, which slightly reduces its effectiveness despite the 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 complexity of a data export tool with no annotations and no output schema, the description is incomplete. It fails to explain what the export produces (e.g., file format, data structure), any side effects, or usage constraints, leaving significant gaps for the agent to understand the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all parameters (habit_id, start_date, end_date, format) with details like defaults and formats. The description adds no additional semantic context beyond the schema, so it meets the baseline score of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export habit tracking data' clearly states the action (export) and resource (habit tracking data), providing a basic purpose. However, it lacks specificity about what 'export' entails (e.g., file generation, data retrieval) and does not differentiate from sibling tools like 'ticktick_export_analytics_data' or 'ticktick_export_project', making it vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, constraints, or sibling tools, leaving the agent without context for selection. For example, it doesn't clarify if this is for bulk data extraction or specific reporting needs.
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 doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format might be (e.g., list of events, structured data). The description is minimal and adds little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, which is efficient and front-loaded. However, it's arguably too brief, bordering on under-specified, but it doesn't waste words. It could benefit from more detail without losing 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 complexity (a tool with 4 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain what the tool returns, how to interpret results, or any behavioral context. The schema covers parameters well, but the overall tool purpose and usage are inadequately described for effective agent invocation.
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 100%, so the schema fully documents all parameters (start_date, end_date, view_type, include_tasks). The description adds no additional meaning beyond what the schema provides, such as explaining the interaction between parameters or typical use cases. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Calendar view for date range' states the general purpose but is vague. It mentions the resource ('calendar view') and scope ('date range'), but lacks a specific verb (e.g., 'get', 'retrieve', 'fetch') and doesn't distinguish it from sibling tools like 'ticktick_get_calendar_events', which might serve a similar purpose. It's not tautological but insufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare it to siblings like 'ticktick_get_calendar_events' or 'ticktick_filter_tasks'. Usage is implied by the name and parameters, but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, data freshness, or what the output looks like. For a tool with no annotations, this is inadequate.
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 a single, efficient sentence that directly states the purpose. It's appropriately sized for a simple tool, though it could be slightly more specific to improve clarity without losing 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what statistics are returned, the format of the analytics, or any behavioral context. For a tool that likely returns structured data, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'period' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get focus time statistics and analytics' states the verb ('Get') and resource ('focus time statistics and analytics'), but it's somewhat vague about what specific statistics are included. It distinguishes from most siblings (which are about tasks, projects, habits, etc.), but doesn't clearly differentiate from similar analytics tools like 'ticktick_get_daily_focus_summary' or 'ticktick_get_focus_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for usage, or exclusions. Given the presence of similar analytics siblings, this lack of differentiation is a significant gap.
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 of behavioral disclosure. It states the tool 'gets' data, implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what the output format looks like (e.g., JSON list of notes). For a read tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get task notes/comments'), consisting of a single, front-loaded phrase that directly states the tool's purpose. There's no wasted verbiage, making it efficient for quick scanning. However, it's arguably too brief, bordering on under-specified, which slightly reduces its effectiveness.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits (e.g., read-only nature, potential errors), output expectations, and how it differs from sibling tools. While the schema covers parameters well, the description doesn't compensate for missing context, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the schema itself (task_id, include_replies, sort_order). The description adds no additional meaning beyond what's in the schema—it doesn't explain what 'notes/comments' entail in relation to the parameters or provide examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get task notes/comments' states the basic action (get) and resource (task notes/comments), making the purpose clear at a high level. However, it's vague about what 'notes/comments' specifically refers to (e.g., are these user comments, internal notes, or both?), and it doesn't distinguish this tool from sibling tools like 'ticktick_get_task_details' or 'ticktick_get_task_attachments', which might also retrieve task-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid task ID), exclusions (e.g., not for editing notes), or sibling tools that might be more appropriate in certain contexts (e.g., 'ticktick_get_task_details' for general task info or 'ticktick_add_task_comment' for adding notes). This leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Project activity feed' implies a read-only operation, but it does not disclose behavioral traits such as whether it requires authentication, rate limits, pagination, or what the output format looks like (no output schema). This leaves significant gaps for an agent to understand how to interact with it effectively.
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 a single phrase, 'Project activity feed', which is concise and front-loaded. It avoids unnecessary words, but it may be overly terse, potentially under-specifying the tool's scope. However, it earns its place by succinctly stating the core function.
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 complexity of a feed tool with no annotations, no output schema, and multiple parameters, the description is incomplete. It does not explain what the feed contains (e.g., team actions), how results are structured, or any limitations (e.g., real-time vs. historical data). This makes it inadequate for an agent to fully understand the tool's behavior and output.
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 100% description coverage, clearly documenting all parameters (project_id, limit, activity_types). The description adds no additional meaning beyond the schema, such as explaining the context of 'activity_types' or default behaviors. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Project activity feed' indicates the tool retrieves activity data for a project, which is a clear purpose. However, it lacks specificity about what 'activity' entails (e.g., team actions like task changes) and does not distinguish from siblings like 'ticktick_get_collaboration_stats' or 'ticktick_get_project_stats', which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a project ID), exclusions, or comparisons to sibling tools like 'ticktick_get_collaboration_stats' for team insights or 'ticktick_get_project_stats' for project metrics, leaving usage ambiguous.
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 of behavioral disclosure. It mentions 'detailed time allocation and tracking analysis' but does not specify if this is a read-only operation, requires authentication, has rate limits, or what the output format entails (e.g., textual summary, structured data). For a reporting tool with zero annotation coverage, this leaves significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it lacks front-loading of critical details (e.g., resource scope) and could be more structured to highlight key aspects, but it earns a high score for 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 the complexity of a reporting tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It does not explain the return values, data format, or behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
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 100%, so the schema already documents all 5 parameters with descriptions and enums. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters or typical use cases. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate detailed time allocation and tracking analysis' states the general purpose (generating analysis) but is vague about the specific resource (e.g., time tracking data from TickTick) and does not distinguish it from sibling tools like 'ticktick_get_productivity_report' or 'ticktick_get_daily_focus_summary', which also involve reporting or analysis. It lacks specificity in verb and resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other reporting tools in the sibling list (e.g., 'ticktick_get_productivity_report' or 'ticktick_get_weekly_summary'). There is no mention of context, prerequisites, or exclusions, leaving the agent without usage direction.
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 of behavioral disclosure. 'Remove project access' implies a destructive mutation, but it fails to specify permissions required, whether the action is reversible, side effects (e.g., loss of task assignments), or error conditions. This leaves significant gaps for safe and effective use.
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 a single, efficient phrase with no wasted words. However, it is overly terse and under-specified, lacking necessary detail for a mutation tool, which slightly reduces its effectiveness despite the concise form.
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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It does not cover behavioral aspects like permissions, reversibility, or expected outcomes, nor does it explain the impact on project collaboration, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions ('ID of the project', 'ID of user to remove'). The description adds no additional meaning beyond the schema, such as format examples or relationship context. Baseline 3 is appropriate as the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove project access' clearly indicates a removal action but is vague about what specifically is being removed. It distinguishes from siblings like 'ticktick_invite_collaborator' by implying removal rather than addition, but lacks specificity about the resource (collaborator access) and context (project collaboration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., user must be a collaborator), exclusions, or related tools like 'ticktick_set_project_permissions' or 'ticktick_share_project', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'advanced search' but doesn't clarify what that entails—such as search scope (e.g., across all tasks or specific projects), performance characteristics, or any limitations. For a search tool with no annotations, this leaves critical behavioral traits undisclosed.
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 a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple search tool, though it could be slightly more informative without losing 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'advanced' means, what the search returns, or how results are structured. For a tool with no structured output information, more context is needed to guide the agent 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 100%, so the schema fully documents both parameters ('query' and 'limit'). The description adds no additional meaning beyond what's in the schema, such as query syntax examples or result ordering. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Advanced search for tasks with text query' clearly states the verb ('search') and resource ('tasks'), but it's vague about what makes it 'advanced' compared to other search tools. It doesn't distinguish itself from sibling tools like 'ticktick_filter_tasks' or 'ticktick_get_tasks_by_tag', leaving the agent uncertain about when to choose this specific search method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for task retrieval (e.g., 'ticktick_filter_tasks', 'ticktick_get_tasks_by_tag'), the description lacks any context about use cases, prerequisites, or comparisons, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Add note to task' implies a mutation operation, but it doesn't specify required permissions, whether the note is editable/deletable, rate limits, or what happens on success/failure (e.g., returns a note ID). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Add note to task' is extremely concise with zero wasted words, making it easy to parse. It's front-loaded with the core action, though this brevity comes at the cost of completeness. For a simple tool, this structure is 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 the tool's complexity (a mutation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain behavioral aspects like side effects, error handling, or return values, leaving the agent under-informed. The high schema coverage helps, but overall context is insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (task_id, note_content, note_type, is_private) with descriptions and defaults. The description adds no additional meaning beyond the schema, such as examples or usage context (e.g., what 'private' means in this system). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add note to task' clearly states the verb ('add') and resource ('note to task'), making the purpose understandable. However, it lacks specificity about what kind of note (e.g., comment, progress update) and doesn't distinguish it from sibling tools like 'ticktick_add_task_comment' or 'ticktick_update_task_note', leaving ambiguity about when to use this versus those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing task), exclusions, or comparisons to siblings like 'ticktick_add_task_comment' (which might be a specific note type) or 'ticktick_update_task_note' (which modifies existing notes). This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It implies a write operation ('import') but doesn't disclose critical traits: whether this is destructive (overwrites existing data), requires specific permissions, has rate limits, or what happens on success/failure. The agent lacks context on safety and operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a tool with a clear name and well-documented schema, though it could be more informative without sacrificing 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 the tool's complexity (bulk import with 4 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain the import's effect (e.g., creates events/tasks), error handling, or output expectations. For a mutation tool with no safety annotations, more context is needed to guide the agent 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 100%, so the schema fully documents all 4 parameters (calendar_data, import_source, merge_duplicates, create_new_calendar). The description adds no additional meaning beyond the schema, such as explaining iCal format details or use cases for parameters. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Import external calendar data' clearly states the action (import) and resource (external calendar data), but it's vague about scope and format. It doesn't specify whether this imports into a calendar view, creates tasks/events, or handles bulk operations, nor does it distinguish from sibling tools like 'ticktick_import_from_csv' or 'ticktick_sync_with_google_calendar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing iCal data), exclusions (e.g., not for CSV imports), or comparisons to siblings like 'ticktick_import_from_csv' or 'ticktick_create_calendar_event', leaving the agent to guess based on 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 carries the full burden of behavioral disclosure. 'Mass task creation' implies a write operation but doesn't specify permissions required, whether it's idempotent, rate limits, or error handling. It mentions 'template' indirectly via the tool name but not in the description, missing key behavioral context for a bulk mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'Mass task creation', a single phrase that front-loads the core purpose without waste. It's appropriately sized for the tool's complexity, though it could benefit from more detail given the lack of annotations.
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 bulk mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain the template-based mechanism, expected outcomes, error scenarios, or how it differs from sibling tools. Given the complexity and lack of structured data, more context is needed to guide the agent 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 100%, with clear descriptions for all parameters (e.g., 'Template to use for bulk creation' for template_id). The description 'Mass task creation' adds minimal value beyond the schema, implying bulk operations but not detailing parameter interactions or semantics. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mass task creation' clearly indicates the tool creates tasks in bulk, which is a specific verb+resource combination. However, it doesn't distinguish itself from sibling tools like 'ticktick_create_task' or 'ticktick_create_task_from_template' beyond the 'mass' aspect, leaving the template-based nature implied but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'ticktick_create_task' (single task creation) or 'ticktick_create_task_from_template' (single task from template). It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Remove' implies a destructive mutation, but it doesn't specify whether this action is reversible, requires specific permissions, or has side effects (e.g., affecting task history). The description lacks critical behavioral details for a deletion 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 just three words, front-loading the core action. There is no wasted language or unnecessary elaboration, making it efficient for quick comprehension.
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 destructive tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after deletion (e.g., confirmation, error cases), return values, or how it interacts with the broader system (e.g., sibling tools like 'ticktick_get_task_notes'). More context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (task_id and note_id). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or relationships between task and note IDs. Baseline 3 is appropriate given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove task note' clearly states the action (remove) and target (task note), making the purpose understandable. However, it doesn't distinguish this tool from other deletion tools in the sibling list like 'ticktick_delete_task' or 'ticktick_delete_task_attachment', leaving the scope somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing note), exclusions, or relationships with sibling tools like 'ticktick_update_task_note' or 'ticktick_get_task_notes', leaving the agent to infer usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering but doesn't describe output format (e.g., list of tasks, pagination), performance characteristics, or any side effects. This is inadequate for a tool with 5 parameters and no output schema, leaving key behaviors unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a filtering tool, though it could be more informative; the brevity is not due to under-specification but concise 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 tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return values, behavioral traits, or usage context, leaving significant gaps for the agent to infer. This is insufficient for effective tool selection and invocation.
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 100%, so the input schema fully documents all 5 parameters. The description adds no additional meaning beyond implying 'various criteria', which is already covered by the schema. This meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Filter tasks by various criteria' states the basic action (filter) and resource (tasks), but it's vague about scope and doesn't distinguish from siblings like 'ticktick_search_tasks' or 'ticktick_get_tasks_by_tag'. It lacks specificity about what 'various criteria' means beyond the generic verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'ticktick_search_tasks' or 'ticktick_get_tasks_by_tag'. The description implies usage for filtering but offers no context, exclusions, or prerequisites, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'List calendar events', implying a read-only operation, but fails to detail aspects like authentication needs, rate limits, pagination, or what the output looks like (since there's no output schema). This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loaded and free of unnecessary details. Every word ('List calendar events') directly contributes to the core purpose, making it efficient and well-structured for quick comprehension.
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 (a read operation with three parameters) and the lack of annotations and output schema, the description is incomplete. It does not explain return values, error handling, or behavioral constraints, making it insufficient for an agent to fully understand the tool's context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters (start_date, end_date, calendar_id) with formats and purposes. The description adds no additional meaning beyond the schema, so it meets the baseline score of 3, as the schema adequately handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List calendar events' clearly states the verb ('List') and resource ('calendar events'), providing a basic understanding of the tool's function. However, it lacks specificity about scope (e.g., all events vs. filtered) and does not differentiate from sibling tools like 'ticktick_get_calendar_view' or 'ticktick_create_calendar_event', making it vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., for viewing vs. creating events), or exclusions, leaving the agent without direction on appropriate 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 provided, the description carries full burden but offers minimal behavioral insight. 'Team productivity metrics' suggests read-only data retrieval, but doesn't specify authentication needs, rate limits, data freshness, or what specific metrics are returned. It doesn't mention whether this aggregates data across collaborators or requires specific permissions.
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 at just two words, with zero wasted text. It's front-loaded with the core concept, though this brevity comes at the cost of completeness. Every word earns its place by conveying the tool's general domain.
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 no annotations and no output schema, the description is inadequate. 'Team productivity metrics' doesn't explain what data is returned, in what format, or what 'collaboration' specifically entails. Given the complexity implied by the name and the lack of structured documentation, the description should provide more context about the tool's behavior and output.
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 100%, so parameters are fully documented in the schema. The description adds no additional parameter context beyond what's already in the schema - it doesn't explain what 'collaboration stats' encompass or how the time period affects the metrics. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Team productivity metrics' is vague - it states the general domain but doesn't specify what action the tool performs (retrieves? calculates? analyzes?) or what resource it operates on. While it hints at collaboration stats, it doesn't clearly distinguish this from similar sibling tools like 'ticktick_get_team_activity' or 'ticktick_get_productivity_report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or comparisons to sibling tools that also provide team/productivity data. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a 'get' operation (implying read-only) but doesn't disclose behavioral traits like authentication needs, rate limits, whether it returns structured data or a report, error conditions, or if it requires specific user permissions. For a tool with no annotation coverage, this is inadequate.
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 with a single sentence that directly states the tool's purpose. No wasted words or unnecessary elaboration. It's front-loaded with the core action, though this brevity contributes to gaps in other dimensions.
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 no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain what the summary contains (e.g., metrics, format), how it's generated, or any dependencies. For a tool that likely returns analytics data, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'date' fully documented in the schema (type, format, default). The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get daily focus time summary' states the basic action (get) and resource (daily focus time summary), but it's vague about what exactly constitutes a 'focus time summary' - is it total minutes, breakdown by task, comparison to goals? It distinguishes from most siblings (which are about tasks, projects, habits, etc.) but not clearly from 'ticktick_get_focus_stats' or 'ticktick_get_focus_history' which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'ticktick_get_focus_stats' or 'ticktick_get_focus_history'. The description doesn't mention prerequisites, context (e.g., requires focus tracking enabled), or exclusions. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Track progress', which implies a read-only operation but doesn't confirm safety (e.g., no mutations), data sources, or potential side effects like rate limits or authentication needs. For a tool with no annotations, this is insufficient—it should describe what 'track' entails, such as retrieving analytics data without modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core purpose ('Track progress'), making it easy to scan. Every part of the sentence contributes to the tool's intent, and there is no unnecessary elaboration or 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 complexity (4 parameters with nested objects, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., read-only nature, data format), doesn't explain the return values or structure, and provides no context on how the tool fits among sibling analytics tools. For a tool with rich input schema but no other structured data, the description should do more to guide usage and expectations.
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 100%, so the schema already documents all parameters (goal_type, time_frame, target_metrics, include_recommendations) with enums and descriptions. The description adds no additional meaning beyond the schema, such as explaining how parameters interact or providing examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Track progress toward personal and team goals' states a general purpose (tracking progress) but lacks specificity. It does not clearly distinguish this tool from sibling analytics tools like 'ticktick_get_completion_trends' or 'ticktick_get_productivity_insights', which also involve progress tracking. The verb 'track' is vague compared to more precise terms like 'analyze' or 'retrieve', and it doesn't specify the resource (e.g., goal data from TickTick).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools focused on analytics (e.g., 'ticktick_get_completion_trends', 'ticktick_get_productivity_insights'), there is no indication of when this tool is preferred, such as for goal-specific metrics versus general productivity. It mentions 'personal and team goals' but doesn't clarify prerequisites or exclusions, leaving usage ambiguous.
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 of behavioral disclosure. The description only states 'Get habit completion history' without mentioning any behavioral traits such as whether this is a read-only operation, if it requires authentication, potential rate limits, or what the output format looks like. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 at just three words ('Get habit completion history'), with zero wasted language. It's front-loaded with the core action and resource. This is an example of efficient communication where every word earns its place.
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 no annotations and no output schema, the description is incomplete for effective tool usage. While the purpose is clear, it lacks crucial behavioral context (e.g., read-only vs. mutation, authentication needs) and doesn't describe what the tool returns. For a tool with 2 parameters and no structured output information, the description should provide more context about the operation and expected results.
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 100% description coverage, with clear documentation for both parameters ('habit_id' and 'days_back'). The description doesn't add any meaningful semantic context beyond what the schema already provides (e.g., it doesn't explain what 'completion history' entails or how the data is structured). Since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get habit completion history' clearly states the verb ('Get') and resource ('habit completion history'), making the purpose understandable. However, it doesn't distinguish this tool from similar siblings like 'ticktick_get_habit_calendar', 'ticktick_get_habit_stats', or 'ticktick_get_habit_streaks', which all appear to retrieve habit-related data. The description is adequate but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that retrieve habit data (e.g., 'ticktick_get_habit_calendar', 'ticktick_get_habit_stats'), there's no indication of what makes this tool unique or when it should be preferred. The description simply states what it does without any contextual usage information.
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 of behavioral disclosure. It states 'Get project analytics and statistics' which implies a read-only operation, but doesn't specify authentication requirements, rate limits, error conditions, or what the output looks like (e.g., format, structure). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 at just four words ('Get project analytics and statistics'), with zero wasted language. It's front-loaded with the core purpose, making it easy to parse quickly without unnecessary elaboration.
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 complexity of analytics tools and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what specific statistics are returned, the format of the analytics data, or any behavioral constraints. For a tool that likely returns structured data, more context is needed to help the agent understand what to expect.
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 100% description coverage, with the single parameter 'project_id' clearly documented as 'ID of the project'. The description doesn't add any additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get project analytics and statistics' clearly states the verb ('Get') and resource ('project analytics and statistics'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'ticktick_get_productivity_insights' or 'ticktick_get_completion_trends' which also appear to provide analytical data, leaving ambiguity about what specifically distinguishes this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools offering analytics (e.g., 'ticktick_get_productivity_insights', 'ticktick_get_completion_trends'), there's no indication of what makes this tool unique or when it should be preferred over others, leaving the agent to guess based on names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. 'List recurring tasks' implies a read-only operation, but it doesn't specify whether this requires authentication, returns paginated results, includes metadata like task details, or has rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, front-loading the core action and resource. There's no wasted language, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
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 complexity (a read operation with filtering parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits like pagination. For a tool with three parameters and no structured output documentation, 'List recurring tasks' is insufficient to guide an agent 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 100%, with all three parameters (project_id, frequency_filter, status) well-documented in the schema. The description adds no additional meaning beyond 'List recurring tasks', which implies filtering but doesn't explain parameter usage or interactions. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List recurring tasks' clearly states the verb ('List') and resource ('recurring tasks'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'ticktick_filter_tasks' or 'ticktick_search_tasks' that also retrieve tasks, nor does it specify scope beyond 'recurring' (e.g., all vs filtered). This makes it vague compared to a more specific description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'ticktick_filter_tasks', 'ticktick_search_tasks', and 'ticktick_get_tasks_by_tag', there's no indication that this tool is specifically for recurring tasks or how it differs from general task retrieval tools. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'List shared projects', which implies a read-only operation, but doesn't disclose behavioral traits such as whether it requires authentication, how results are returned (e.g., pagination, format), or any rate limits. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('List shared projects') with zero wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
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 complexity of listing shared projects (which may involve permissions or filtering), no annotations, and no output schema, the description is incomplete. It lacks details on return values, error handling, or any contextual nuances, making it inadequate for an agent to fully understand the tool's behavior and output.
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 100% description coverage, clearly documenting both parameters (include_owned and include_received) with their purposes and defaults. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List shared projects' clearly states the action (list) and resource (shared projects), providing a basic purpose. However, it doesn't differentiate from the sibling tool 'ticktick_get_projects' which likely lists all projects, making the distinction between 'shared' and general projects unclear without further context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'ticktick_get_projects'. The description implies it's for shared projects, but it doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence: 'Get detailed information about a specific task'. It is front-loaded and wastes no words, making it easy to parse. Every part of the sentence contributes to understanding the tool's basic function.
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 complexity of a task management system and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, such as fields like due dates or status, nor does it cover behavioral aspects like error handling. For a tool with no structured output, more descriptive context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'task_id' clearly documented as 'ID of the task'. The description adds no additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get detailed information about a specific task', which is clear but vague. It specifies the verb 'get' and resource 'task', but lacks specificity on what 'detailed information' entails, making it less distinct from siblings like 'ticktick_get_task_attachments' or 'ticktick_get_task_notes' that might also retrieve task-related data. It avoids tautology but doesn't fully differentiate scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid task ID, or compare it to sibling tools like 'ticktick_search_tasks' or 'ticktick_get_tasks_by_tag' for broader queries. Usage is implied only by the name, with no explicit context 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'List task templates' implies a read-only operation but doesn't specify permissions required, rate limits, pagination, or what the output looks like (e.g., list of objects with fields). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 at three words, with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by defining the tool's basic purpose.
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 no annotations and no output schema, the description is incomplete for a tool that returns data. It doesn't explain what 'listing' entails (e.g., format, fields, pagination), which is critical for an agent to use it effectively. The high schema coverage helps with inputs, but output behavior remains undocumented.
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 100%, with all three parameters well-documented in the schema itself (category filtering, shared inclusion, sort options). The description adds no additional parameter context beyond what the schema provides, so it meets the baseline for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List task templates' clearly states the verb ('List') and resource ('task templates'), providing a basic understanding of the tool's function. However, it lacks specificity about scope or format, and doesn't differentiate from sibling tools like 'ticktick_get_project_templates' or 'ticktick_bulk_create_from_template' that might involve templates in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for filtering templates, or distinguish it from related tools such as 'ticktick_create_task_from_template' or 'ticktick_update_task_template'. The agent must infer usage solely from the name and parameters.
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. 'Temporarily stop recurrence' suggests a mutation (pausing), but it doesn't disclose behavioral traits like whether this requires specific permissions, if the pause is reversible, what happens to scheduled instances, or if there are rate limits. The description is minimal and lacks critical context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase 'Temporarily stop recurrence', which is front-loaded and wastes no words. It efficiently conveys the core action without unnecessary elaboration, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'temporarily' means (e.g., duration or resumption behavior), the effect on task status, or return values. Given the complexity of pausing recurrence, more context is needed to understand the tool's behavior fully.
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 100%, with clear descriptions for all three parameters (task_id, pause_reason, resume_date). The description adds no additional meaning beyond the schema, such as explaining parameter interactions or constraints. Baseline 3 is appropriate since the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Temporarily stop recurrence' states the action (stop) and target (recurrence) but is vague about the resource (task) and doesn't differentiate from sibling tools like 'ticktick_pause_habit' or 'ticktick_pause_focus_session'. It implies pausing a recurring task but lacks specificity about what 'recurrence' refers to in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., task must be recurring), exclusions, or compare to siblings like 'ticktick_set_recurring_task' for modifying recurrence or 'ticktick_update_task' for other changes. Usage is implied only by the tool name and description.
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. 'Customize' implies a mutation, but it doesn't disclose behavioral traits like whether changes are reversible, permission requirements, rate limits, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single phrase ('Customize project appearance'). It's front-loaded and wastes no words, though this conciseness contributes to vagueness in other dimensions. Every word earns its place.
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 a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error handling, or what the tool returns. For a tool that modifies project settings, more context is needed to guide an agent 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 100%, with clear parameter descriptions ('ID of the project', 'New color (hex code)'). The description adds no additional meaning beyond the schema, such as examples or constraints (e.g., valid color ranges). Baseline is 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Customize project appearance' states the general purpose but is vague. It doesn't specify the exact action (setting color) or distinguish from potential sibling tools like 'ticktick_reorder_projects' or 'ticktick_set_project_permissions' that also customize appearance. The tool name 'ticktick_set_project_color' is more specific than the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing project), exclusions, or compare with related tools like 'ticktick_update_project' (if it existed) or other appearance-related operations. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. 'Start a focus/Pomodoro session' implies a write operation that initiates a timed session, but it doesn't disclose critical behaviors such as whether this requires specific permissions, what happens if a session is already active, if it's idempotent, or what the expected outcomes are (e.g., does it return a session ID?). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Start a focus/Pomodoro session') with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
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 complexity of starting a focus session (a mutation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, usage context, and expected outputs, failing to compensate for the absence of structured data. This makes it inadequate for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, detailing all three parameters (task_id, duration, session_type) with defaults and types. The description adds no parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a focus/Pomodoro session' clearly states the action (start) and resource (focus/Pomodoro session), but it's somewhat vague about what 'starting' entails operationally. It doesn't distinguish this tool from sibling tools like 'ticktick_pause_focus_session' or 'ticktick_stop_focus_session' beyond the verb, leaving room for ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a task must exist), when to choose different session types, or how it relates to sibling tools like pause/resume/stop focus sessions, leaving the agent with no contextual usage cues.
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 full burden but only states the action without behavioral details. It doesn't disclose if this is a destructive mutation, what permissions are required, how errors are handled, or the response format. For a mutation tool, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though this conciseness comes at the cost of detail, which is reflected in lower scores for other dimensions.
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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error handling, or return values, making it inadequate for safe and effective use by an AI agent in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (tag_id, name, color). The description adds no additional meaning beyond implying an update action, which is already clear from the tool name. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing tag' clearly states the action (update) and resource (tag), but it's vague about what aspects can be updated. It doesn't distinguish from sibling tools like 'ticktick_create_tag' or 'ticktick_delete_tag' beyond the basic verb difference, missing specificity about scope or fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing tag ID), exclusions, or comparisons to siblings like 'ticktick_merge_tags' or 'ticktick_create_tag', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Edit task note' implies a mutation operation, but it doesn't disclose behavioral traits such as permissions required, whether edits are reversible, rate limits, or what happens on success/failure. This leaves significant gaps in understanding the tool's behavior beyond basic intent.
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 'Edit task note', a single phrase that front-loads the core purpose without waste. Every word earns its place, making it efficient for quick understanding, though it may lack depth.
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 (a mutation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or return values, leaving the agent with insufficient information to invoke it correctly beyond basic parameter mapping.
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 100%, with clear descriptions for 'task_id', 'note_id', and 'new_content'. The description adds no additional meaning beyond the schema, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit task note' states the action (edit) and resource (task note), which is clear but minimal. It distinguishes from obvious siblings like 'ticktick_add_task_note' and 'ticktick_delete_task_note' by specifying editing rather than adding or deleting, but it lacks specificity about what editing entails (e.g., content replacement). This is vague compared to more detailed descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing note), exclusions, or comparisons to similar tools like 'ticktick_update_task' for other task modifications. Without such context, an agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, or what the response format looks like. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words, which is appropriate for a simple tool. It's front-loaded with the core purpose. However, it could be slightly more informative without sacrificing 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?
For a tool with no annotations, no output schema, and no parameters, the description is insufficient. It doesn't explain what user profile information is returned, the format of the response, or any behavioral characteristics. The agent would need to guess about the output structure and operational behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for any parameter gaps, and appropriately doesn't mention parameters since none exist. This meets the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user profile information' clearly states the action (get) and resource (user profile), but it's vague about what specific information is retrieved. It distinguishes from siblings by focusing on user data rather than tasks or projects, but lacks specificity about the profile content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, authentication requirements, or differentiate it from other user-related tools like 'ticktick_update_user_settings' or 'ticktick_get_notification_settings'.
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. 'Add a tag' implies a mutation operation, but the description doesn't disclose behavioral traits like whether this requires specific permissions, if it's idempotent (adding an existing tag), what happens on success/failure, or any rate limits. It provides minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool and front-loads the core action. Every word earns its place without redundancy or fluff.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success confirmation, updated task object), error conditions, or side effects. Given the complexity (adding a tag to a task) and lack of structured data, more behavioral context is needed.
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 100%, with both parameters ('task_id' and 'tag_name') clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., format of IDs, tag naming rules, or examples). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a tag') and target ('to a specific task'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'ticktick_remove_tag_from_task' or 'ticktick_bulk_tag_operations', which handle similar tag-related operations 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., the tag must exist), when to choose this over bulk operations, or what happens if the tag is already on the task. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if archiving is reversible, requires specific permissions, affects project data/tasks, or has side effects like making the project read-only or hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and target, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on what archiving entails (e.g., state changes, data persistence), reversal options, error conditions, or return values, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter ('project_id') fully documented in the schema. The description adds no additional parameter semantics beyond implying the project must be 'completed', which isn't reflected in the schema. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive') and target ('a completed project'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'ticktick_unarchive_project' or explain what 'archive' means in this context versus deletion or other project management operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'completed project' suggesting when to use it, but offers no explicit alternatives (e.g., when to use vs. delete, move, or other project tools), no prerequisites, and no mention of sibling tools like 'ticktick_unarchive_project' for reversal.
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 of behavioral disclosure. 'Assign task to team member' implies a mutation operation, but it doesn't disclose any behavioral traits: no mention of permissions required, whether it's reversible, rate limits, side effects (e.g., notifications sent), or what the response looks like (success/failure indicators). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('Assign task to team member'), making it immediately scannable and appropriately sized for its purpose.
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 this is a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks critical context: behavioral traits (permissions, reversibility), usage guidelines (vs. siblings), and output expectations. The 100% schema coverage helps with parameters, but overall completeness is inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters with clear descriptions and enum values. The description adds no additional meaning beyond what's in the schema (e.g., no examples, format details for 'due_date', or context for 'notification'). Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Assign task to team member' clearly states the verb ('assign') and resource ('task'), making the purpose immediately understandable. It distinguishes from obvious siblings like 'ticktick_create_task' (creation vs. assignment) and 'ticktick_update_task' (general update vs. specific assignment), though it doesn't explicitly differentiate from 'ticktick_bulk_assign_tasks' (single vs. bulk).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing task and team member), exclusions (e.g., not for unassigned tasks), or comparisons to siblings like 'ticktick_bulk_assign_tasks' for multiple assignments or 'ticktick_update_task' for other modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('check in multiple habits') but lacks details on permissions, rate limits, side effects, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's function, making it easy to parse quickly.
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 complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like error handling, success indicators, or prerequisites, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters. The description adds no additional meaning beyond implying bulk operation, which is already suggested by the tool name. Baseline 3 is appropriate as the schema handles the parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('check in') and resource ('multiple habits'), making the purpose evident. However, it doesn't explicitly differentiate from its sibling 'ticktick_checkin_habit', which handles single habit check-ins, though the 'bulk' prefix implies this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention using 'ticktick_checkin_habit' for single habits or clarify if this is for efficiency or batch operations, leaving the agent without context for selection.
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 full burden but lacks behavioral details. It doesn't disclose if this is a mutation (likely, given 'check in'), permission requirements, rate limits, or what happens on success/failure (e.g., updates habit streaks). The phrase 'for today' hints at date constraints but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('Check in a habit'), making it easy to parse quickly, though its brevity contributes to gaps in other dimensions.
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 no annotations, no output schema, and a mutation tool (implied by 'check in'), the description is incomplete. It lacks details on behavioral traits, error handling, or return values, making it inadequate for safe and effective use by an AI agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying date defaults to today and count defaults to 1, which are already in schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check in a habit for today' clearly states the verb ('Check in') and resource ('a habit'), making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'ticktick_bulk_checkin_habits' or 'ticktick_update_habit', which handle multiple habits or modifications rather than single check-ins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., habit must exist), exclusions (e.g., cannot check in past dates beyond a limit), or comparisons to siblings like 'ticktick_bulk_checkin_habits' for multiple habits, leaving usage context implied at best.
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 full burden for behavioral disclosure. 'Mark a task as completed' implies a mutation operation, but it doesn't specify whether this is reversible, what permissions are required, if it triggers notifications, or what happens to recurring tasks. For a mutation tool with zero annotation coverage, this leaves significant 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 a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it immediately understandable.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'completed' means in this context (e.g., moves to completed list, changes status), doesn't mention side effects, and provides no information about return values or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's in the schema, which has 100% coverage for the single 'task_id' parameter. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even without additional param details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark as completed') and resource ('a task'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'ticktick_update_task' which might also handle completion status, so it doesn't achieve full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., task must exist), when not to use it (e.g., for archiving vs. completing), or how it relates to sibling tools like 'ticktick_update_task' that might offer similar functionality.
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 states the tool performs a conversion but doesn't disclose behavioral traits like whether it validates input formats, handles errors, returns specific output structures, or has any side effects. For a utility tool with no annotation coverage, this leaves the agent guessing about reliability and output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It's appropriately sized for a simple utility tool and front-loads the core purpose immediately. Every word earns its place in this minimal but complete statement.
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 no annotations, no output schema, and operates in a context with many datetime-related sibling tools, the description is insufficient. It doesn't explain what the converted format looks like, how errors are handled, or typical integration patterns with other TickTick tools. For a utility that likely feeds into other API calls, this leaves too many unknowns for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema. The description adds no additional parameter semantics beyond what the schema already provides (e.g., example datetime formats, timezone handling details). According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'convert' and the resource 'datetime to TickTick API format', making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like date/time formatters in other contexts, though no direct siblings exist in this server list. The description avoids tautology by specifying the conversion target format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical use cases (e.g., preparing datetime inputs for other TickTick API calls), or when not to use it. Given the sibling tools include many datetime-related operations (like create_calendar_event), this lack of contextual guidance is a significant gap.
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 of behavioral disclosure. It states 'Create' implies a write operation, but doesn't cover critical aspects like whether this requires specific permissions, if it's idempotent, what happens on failure, or if there are rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple creation tool and front-loads the essential information. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., project ID, success status), error conditions, or behavioral constraints. While the schema covers inputs well, the overall context for safe and effective use is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for all three parameters. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description. The description doesn't compensate but doesn't need to given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new project in TickTick'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'ticktick_create_project_folder' or 'ticktick_create_project_from_template' by focusing on basic project creation. However, it doesn't explicitly differentiate from all siblings, such as 'ticktick_duplicate_project', which might also create projects in some contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'ticktick_create_project_from_template' or 'ticktick_duplicate_project', nor does it specify prerequisites like authentication or project limits. This leaves the agent without context for tool selection among the many sibling tools.
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 of behavioral disclosure. It states it's a creation tool, implying a write operation, but doesn't mention potential side effects, permissions required, rate limits, or what happens on failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple creation tool.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like error handling, return values, or usage context, which are critical for an agent to invoke it correctly in a real-world scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters (name and color). The description doesn't add any extra meaning beyond the schema, such as explaining naming conventions or color usage, but the schema adequately covers the basics, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new project folder'), specifying its purpose for organization. It distinguishes from siblings like 'ticktick_create_project' by focusing on folders rather than projects, though it doesn't explicitly mention this distinction in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'ticktick_create_project' or 'ticktick_move_project_to_folder'. The description lacks context about prerequisites, such as whether the user needs specific permissions or if there are limits on folder creation.
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 full burden for behavioral disclosure. While 'Create' implies a write operation, it doesn't specify whether this requires authentication, what happens on duplicate tag names, whether there are rate limits, or what the typical response looks like (success/failure indicators). The description provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the essential information and wastes no space on redundant or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a tag is in the TickTick context, doesn't mention potential constraints (like tag name uniqueness), and provides no information about the return value or error conditions. Given the complexity of a write operation in a task management system, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with both parameters ('name' and 'color') clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema, so it meets but doesn't exceed the baseline expectation for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new tag in TickTick'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'ticktick_update_tag' which modifies existing tags, nor does it mention that tags are distinct from projects or tasks in the TickTick system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that tags are used for organizing tasks, nor does it reference the sibling tool 'ticktick_get_tags' for listing existing tags before creation, or 'ticktick_update_tag' for modifying tags. There's no context about prerequisites or when this operation is appropriate.
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 of behavioral disclosure. 'Create a new task' implies a write operation, but it doesn't specify required permissions, whether the task is saved immediately, if there are rate limits, or what happens on failure (e.g., duplicate titles). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Create a new task'), making it easy to parse quickly. Every part of the sentence earns its place by directly stating the tool's function.
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 complexity of a task creation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It lacks context on behavioral aspects (e.g., error handling, permissions), doesn't explain return values or success indicators, and offers no guidance on parameter interactions. For a mutation tool, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the input schema (e.g., 'title' as task title, 'priority' with numeric mapping). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., how 'project_id' affects task placement) or usage tips. Baseline 3 is appropriate when the schema handles most of the documentation.
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 'Create a new task in TickTick' clearly states the verb ('Create') and resource ('task in TickTick'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'ticktick_create_task_from_template' or 'ticktick_create_task_template', which also involve task creation but with different approaches or resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'ticktick_create_task_from_template' and 'ticktick_create_task_template', it's unclear if this is for basic task creation or if there are specific contexts (e.g., from scratch vs. using templates) that should dictate choice. No exclusions 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the operation is 'permanently' destructive, which is valuable, but doesn't address other critical aspects: whether deletion requires special permissions, if it's reversible, what happens to associated data (like habit history), or what the response looks like. For a destructive operation with zero annotation coverage, this is insufficient.
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 three-word phrase that communicates the core action. Every word earns its place: 'Delete' specifies the action, 'habit' specifies the resource, and 'permanently' adds crucial behavioral context. There's zero waste or 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?
For a destructive operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'permanently' entails operationally, doesn't mention error conditions or permissions required, and provides no information about return values or confirmation. The high schema coverage helps with parameters, but behavioral context is critically lacking for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with the single parameter 'habit_id' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema (which states it's 'ID of the habit to delete'). This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a habit'), making the purpose immediately understandable. It specifies 'permanently' which adds important context about the operation's nature. However, it doesn't differentiate from sibling tools like 'ticktick_delete_task' or 'ticktick_delete_tag' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing the habit ID), when deletion is appropriate versus archiving or pausing, or what happens after deletion. The sibling list includes related tools like 'ticktick_pause_habit' and 'ticktick_update_habit' but no comparison is provided.
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. 'Delete a tag permanently' implies a destructive, irreversible mutation, which is helpful. However, it lacks critical details: whether it requires specific permissions, what happens to tasks using the tag (e.g., if they become untagged), error conditions, or response format. For a destructive tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, and 'permanently' adds necessary gravity without verbosity. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral nuances (e.g., cascading effects, auth needs), error handling, or return values. While concise, it fails to provide enough context for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'tag_id' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., format examples, sourcing tips). According to rules, when coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a tag'), with the qualifier 'permanently' adding specificity. It distinguishes from sibling tools like 'ticktick_update_tag' or 'ticktick_remove_tag_from_task' by emphasizing permanent removal rather than modification or detachment. However, it doesn't explicitly contrast with all deletion-related siblings (e.g., 'ticktick_delete_task'), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., tag must exist, no active dependencies), compare to 'ticktick_merge_tags' for consolidation, or warn about irreversible effects. With many sibling tools, the lack of context leaves the agent guessing about appropriate 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 provided, the description carries the full burden of behavioral disclosure. It states 'Delete' which implies a destructive mutation, but doesn't specify whether this is permanent, reversible, requires specific permissions, or what happens to associated data (e.g., attachments, comments). This leaves significant gaps in understanding the tool's 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?
The description is a single, direct sentence that efficiently communicates the core function without any unnecessary words. It's perfectly front-loaded and wastes no space, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'Delete' entails (permanent removal? moves to trash?), doesn't mention authentication or error handling, and provides no information about return values or side effects. This leaves the agent with incomplete context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'task_id' clearly documented. The description doesn't add any additional parameter information beyond what's in the schema, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a task from TickTick'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ticktick_complete_task' or 'ticktick_archive_project' which might also remove tasks in different ways, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'ticktick_complete_task' or 'ticktick_archive_project', nor does it mention prerequisites or consequences. It simply states what the tool does without contextual usage information.
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 of behavioral disclosure. 'Download attached files' implies a read operation, but it doesn't specify whether this requires authentication, has rate limits, returns file data or a download link, or handles errors. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with zero wasted language. It's front-loaded and directly communicates the core function without unnecessary elaboration, making it efficient for an agent to parse.
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 (a download operation with 3 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., file content, download URL), error conditions, or dependencies on other tools, leaving critical gaps for an agent to use it 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?
The input schema has 100% description coverage, with clear parameter descriptions and an enum for 'download_format'. The description adds no additional meaning beyond the schema, such as explaining what 'original' vs 'compressed' entails or how to obtain task/attachment IDs. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Download attached files' clearly states the action (download) and resource (attached files), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'ticktick_get_task_attachments' (which likely lists attachments rather than downloading them), so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing attachment IDs from another tool) or compare it to sibling tools like 'ticktick_get_task_attachments' or 'ticktick_upload_task_attachment', leaving the agent to infer usage 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create a copy' implies a write operation, it doesn't specify whether this requires special permissions, what happens to the original project, whether tasks are duplicated by default, or what the response looks like. The description mentions copying but lacks crucial behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what gets duplicated beyond the basic project structure, doesn't mention permissions or side effects, and provides no information about the return value. Given the complexity of project duplication operations, more context is needed.
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 100%, so all parameters are documented in the schema. The description doesn't add any additional semantic context beyond what's already in the parameter descriptions (project ID, new name, include tasks flag). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a copy') and resource ('existing project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_create_project_from_template' or 'ticktick_export_project', which also involve project creation/copying operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when duplication is appropriate versus creating a new project from scratch or using templates, nor any prerequisites or constraints for using this operation.
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 of behavioral disclosure but only states the basic action. It doesn't cover critical aspects like whether this is a read-only operation, potential data volume or rate limits, authentication requirements, or what the export output entails (e.g., file download, data stream). This leaves significant gaps for a tool that handles analytics data export.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It avoids redundancy and wastes no space, making it easy to parse quickly while conveying the essential action and goal.
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 5 parameters, nested objects, and no output schema or annotations, the description is insufficient. It lacks details on behavioral traits, output format expectations, error handling, or usage context. Given the complexity and absence of structured metadata, the description should provide more completeness to guide effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what the input schema provides. Given the high schema description coverage (80%), the baseline score is 3, as the schema adequately documents parameters like 'data_types', 'date_range', and 'format'. However, the description doesn't compensate for the 20% coverage gap or provide additional context on parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and resource ('raw analytics data') with a purpose ('for external analysis'), making the tool's function immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_export_habit_data' or 'ticktick_export_project', which have overlapping export functions but different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other export tools in the sibling list (e.g., 'ticktick_export_habit_data' for habit-specific data). It lacks context on prerequisites, use cases, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'cached' tasks and optional filtering, but doesn't disclose key behavioral traits: what 'cached' means (e.g., freshness, sync status), whether this is a read-only operation, potential rate limits, or what the output looks like. The description is too vague for a tool that likely involves data retrieval.
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 a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more informative without losing 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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'cached' entails, the format or scope of returned tasks, or any limitations. For a data retrieval tool with potential complexity around caching, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds minimal value beyond the schema by implying project filtering, but doesn't explain parameter interactions (e.g., how 'include_stale' relates to 'cached') or provide usage examples. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all cached tasks') and resource ('cached tasks'), with an optional filter ('by project'). It distinguishes from siblings like 'ticktick_get_tasks_by_tag' or 'ticktick_filter_tasks' by specifying 'cached' tasks, but doesn't explicitly differentiate from 'ticktick_get_task_details' or 'ticktick_search_tasks' in terms of scope or freshness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it mentions optional filtering by project, but doesn't specify when to use this tool versus alternatives like 'ticktick_filter_tasks', 'ticktick_search_tasks', or 'ticktick_get_task_details'. No context on prerequisites, timing, or exclusions is given.
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 of behavioral disclosure. It states the tool analyzes trends but doesn't describe what the output looks like (e.g., data format, metrics included), whether it's a read-only operation, if it requires specific permissions, or any rate limits. For an analytics tool with no structured behavioral hints, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Analyze task completion patterns and trends over time.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every word earns its place by clarifying the tool's function.
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 (analytics with 5 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return values, behavioral traits, or usage context. While the schema covers parameters well, the description fails to compensate for missing annotations and output details, leaving gaps for an agent to understand the tool fully.
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 100% description coverage, so all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond implying analysis of 'task completion patterns and trends,' which aligns with the schema but doesn't provide extra context like how filters interact or what 'predictions' entail. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze task completion patterns and trends over time.' It specifies the verb ('analyze') and resource ('task completion patterns and trends'), making it distinct from most sibling tools that focus on CRUD operations or specific data retrieval. However, it doesn't explicitly differentiate from other analytics tools like 'ticktick_get_productivity_insights' or 'ticktick_get_monthly_insights,' which could also involve trend analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, ideal scenarios, or comparisons to sibling analytics tools. For example, it doesn't clarify if this is for historical analysis only or how it differs from 'ticktick_get_productivity_report.' This lack of context makes it harder for an agent to select the right tool.
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. 'Get historical focus session data' implies a read-only operation but doesn't specify authentication requirements, rate limits, data format, pagination, or what constitutes a 'focus session.' This leaves significant behavioral aspects undocumented for a tool that presumably accesses historical user data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple data retrieval tool and front-loads the essential 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?
For a tool accessing historical user data with no annotations and no output schema, the description is insufficient. It doesn't explain what data is returned (e.g., session duration, timestamps, completion status), how results are structured, or any limitations. Given the complexity of focus session data and lack of structured documentation, more context is needed.
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 100%, with both parameters ('days_back' and 'task_id') well-documented in the schema. The description doesn't add any parameter semantics beyond what the schema already provides, so it meets the baseline of 3 for high schema coverage without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get historical focus session data' clearly states the verb ('Get') and resource ('historical focus session data'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ticktick_get_focus_stats' or 'ticktick_get_daily_focus_summary' which might provide related but different focus data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to focus (e.g., 'ticktick_get_focus_stats', 'ticktick_get_daily_focus_summary'), there's no indication of what makes this tool distinct or when it should be preferred over those options.
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 but only states what the tool does without behavioral details. It doesn't disclose if this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., calendar grid, JSON structure). This is inadequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain the return values (e.g., what the calendar view contains, format), behavioral traits, or error handling. For a data retrieval tool, this leaves significant gaps in understanding how to interpret results.
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 100%, so the schema fully documents the parameters (habit_id, year, month). The description adds no additional meaning beyond implying a calendar view, which is already covered by the tool's name and title. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get calendar view') and resource ('habit completions'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'ticktick_get_habit_history' or 'ticktick_get_habit_stats', which might provide related habit data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or comparisons to siblings like 'ticktick_get_habits_summary' or 'ticktick_get_habit_streaks', leaving the agent with no usage direction.
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 states it's a read operation ('Get'), implying it's non-destructive, but doesn't disclose any behavioral traits like authentication needs, rate limits, pagination, or what 'all habits' entails (e.g., scope, format). For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with one parameter) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'all habits' returns (e.g., list format, fields), potential limitations, or error conditions, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'include_archived' fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline score of 3 for adequate coverage without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all habits from TickTick'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other habit-related tools like 'ticktick_get_habit_calendar' or 'ticktick_get_habits_summary' in the sibling list, which would require more specificity for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to habits (e.g., ticktick_get_habit_calendar, ticktick_get_habits_summary), there's no indication of when this general 'get all habits' tool is preferred over more specific ones, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get daily summary' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, potential rate limits, or what the output format looks like. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a summary tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the summary contains (e.g., habit completion rates, streaks), how it's formatted, or any prerequisites. This makes it inadequate for an agent to fully understand the tool's behavior and output.
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 100% description coverage, with the single parameter 'date' fully documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't clarify what 'summary' includes or how the date parameter affects the output), so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('daily summary of all habits'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'ticktick_get_habits' or 'ticktick_get_habit_stats', which could provide similar habit-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to habits (e.g., 'ticktick_get_habits', 'ticktick_get_habit_stats'), there's no indication of what makes this summary tool distinct or when it's preferred over others.
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 of behavioral disclosure. It mentions 'deep monthly performance insights and recommendations' but fails to specify whether this is a read-only operation, requires specific permissions, involves data processing that might be resource-intensive, or what the output format looks like. This is inadequate for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (5 parameters, nested objects, no output schema) and lack of annotations, the description is insufficient. It doesn't cover behavioral aspects like data sources, processing time, or output structure, leaving significant gaps for an agent to understand how to use this 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?
The schema description coverage is 80%, which is high, so the baseline score is 3. The description does not add any meaningful parameter semantics beyond what the schema already provides (e.g., it doesn't explain how 'insight_depth' levels differ or what 'focus_metrics' entail in practice), so it doesn't compensate for the 20% gap but doesn't detract either.
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 'Generate deep monthly performance insights and recommendations' clearly states the verb ('Generate') and resource ('monthly performance insights and recommendations'), making the purpose understandable. However, it doesn't specifically differentiate from sibling tools like 'ticktick_get_productivity_insights' or 'ticktick_get_weekly_summary' beyond the 'monthly' timeframe, which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, ideal scenarios, or compare it to similar tools like 'ticktick_get_productivity_insights' or 'ticktick_get_weekly_summary', leaving the agent without context for selection.
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 of behavioral disclosure. It states the action ('Get') but fails to mention whether this is a read-only operation, if it requires specific permissions, how results are sorted or paginated, or what the output format looks like. This leaves significant gaps in understanding the tool's 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?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple retrieval tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is incomplete. It doesn't address behavioral aspects like authentication needs, rate limits, or output structure, which are crucial for a tool that retrieves data. For a retrieval tool with no structured support, this description falls short of providing sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'limit' clearly documented in the input schema. The description adds no additional parameter information beyond implying retrieval of tasks, which is already covered by the tool's name and purpose. This meets the baseline for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('overdue tasks') with a specific scope ('all'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_get_today_tasks' or 'ticktick_get_upcoming_tasks' beyond the 'overdue' qualifier, which is why it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'ticktick_filter_tasks' or 'ticktick_search_tasks' for more complex queries. It lacks any context about prerequisites, such as whether authentication is required or if it applies to specific projects, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, returns paginated results, includes rate limits, or what format the projects are returned in. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information ('Get all projects').
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 no annotations and no output schema, the description is insufficiently complete. It doesn't explain what data is returned (project fields, structure), whether authentication is required, or how results are formatted. While the tool is simple (one optional parameter), the lack of behavioral and output context creates significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter 'include_archived' is fully documented in the schema. The description doesn't add any parameter information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline score of 3 reflects adequate but not enhanced parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all projects from TickTick'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_shared_projects' or 'get_project_folders', but the scope 'all projects' provides reasonable distinction for this read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_shared_projects' or 'get_project_folders'. There's no mention of prerequisites, context, or comparison with sibling tools that might retrieve similar data with different filters or scopes.
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 of behavioral disclosure. 'List' implies a read operation, but it doesn't specify whether this requires authentication, returns paginated results, includes metadata (e.g., template descriptions), or has rate limits. For a tool with no annotation coverage, this minimal description leaves key behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('List') and resource ('available project templates'), making it easy to parse. Every word earns its place, achieving optimal conciseness for such a simple tool.
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 simplicity (one optional parameter, no output schema, no annotations), the description is incomplete. It lacks context on usage scenarios, behavioral traits (e.g., authentication needs, return format), and how it fits among sibling template/project tools. While concise, it doesn't provide enough information for an agent to use it effectively without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the input schema has one optional parameter ('category') with 100% description coverage ('Filter by template category'). Since schema coverage is high, the baseline is 3. The description adds no value beyond the schema, but it doesn't need to compensate for gaps either.
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 'List available project templates' clearly states the verb ('List') and resource ('available project templates'), making the purpose immediately understandable. It distinguishes from siblings like 'ticktick_create_project_from_template' (creation vs. listing) and 'ticktick_get_task_templates' (project vs. task templates), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing project access), typical use cases (e.g., before creating a project), or when not to use it (e.g., if you already know the template ID). With many sibling tools for templates and projects, this lack of context is a significant gap.
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 of behavioral disclosure. It states 'Get' implies a read operation, but doesn't clarify if this requires specific permissions, whether it returns real-time or cached data, potential rate limits, or error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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 that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the essential information ('Get device synchronization configuration and status'), making it easy for an agent to parse quickly. Every word earns its place, with no redundancy or fluff.
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 complexity of sync settings (which could involve multiple devices, statuses, and configurations), the description is incomplete. No annotations exist to provide safety or behavioral hints, and there's no output schema to describe the return structure. The description doesn't address what 'configuration and status' entails, potential response formats, or error handling, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('include_device_list' and 'include_sync_history') clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, such as explaining why these options matter or their impact on the response. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('device synchronization configuration and status'), making the purpose immediately understandable. It distinguishes itself from siblings like 'ticktick_update_sync_settings' by focusing on retrieval rather than modification. However, it doesn't explicitly differentiate from other 'get' tools that might involve sync-related data, such as 'ticktick_get_calendar_events' or 'ticktick_get_shared_projects', which could involve sync aspects but aren't specifically about device sync settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing sync enabled), exclusions (e.g., not for modifying settings), or direct alternatives like 'ticktick_update_sync_settings' for changes. The agent must infer usage from the tool name and context alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get usage statistics', implying a read-only operation, but does not disclose behavioral traits such as what statistics are included (e.g., count, frequency), whether it requires authentication, rate limits, or error conditions. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 is incomplete. It does not explain what 'usage statistics' entail (e.g., numeric data, trends), the return format, or any prerequisites. For a tool that likely returns data analytics, this leaves the agent with insufficient context to understand the output or usage implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'tag_id' fully documented in the schema. The description adds no additional meaning beyond the schema, such as examples of tag IDs or context on where to obtain them. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'usage statistics for a specific tag', making the purpose understandable. However, it does not differentiate from sibling tools like 'ticktick_get_tags' or 'ticktick_get_tasks_by_tag', which are also read operations but for different data, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention when to prefer this over 'ticktick_get_tags' (which lists tags) or 'ticktick_get_tasks_by_tag' (which retrieves tasks with a tag), leaving the agent without context for selection.
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 of behavioral disclosure. 'List task assignees' implies a read-only operation, but it doesn't specify whether this requires authentication, what the return format is (e.g., list of names/IDs), error conditions (e.g., invalid task ID), or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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?
The description is extremely concise ('List task assignees')—a single, front-loaded phrase with zero wasted words. It efficiently conveys the core purpose without unnecessary elaboration, making it easy for an agent to parse quickly. Every word earns its place, though this conciseness comes at the cost of detail in other dimensions.
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 complexity (a read operation with one parameter), the description is incomplete. With no annotations and no output schema, the description doesn't cover behavioral aspects (e.g., authentication needs, return format) or usage context. While the schema fully documents the parameter, the overall tool understanding remains shallow, making it inadequate for reliable agent invocation without additional inference.
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 100% description coverage (the 'task_id' parameter is fully documented in the schema), so the baseline score is 3. The description adds no additional parameter information beyond what the schema provides—it doesn't explain the format of the task ID, provide examples, or clarify that this tool is for a single task. This meets the minimum viable level given the schema's completeness.
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 'List task assignees' clearly states the verb ('List') and resource ('task assignees'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'ticktick_assign_task' (which assigns rather than lists) and 'ticktick_get_task_details' (which gets broader details). However, it doesn't specify that this is for a specific task (implied by the parameter), which slightly limits differentiation from other listing 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid task ID), exclusions, or comparisons to siblings like 'ticktick_get_task_details' (which might include assignee info) or 'ticktick_filter_tasks' (which could filter by assignee). Usage is implied by the parameter but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'List' implies a read-only operation, but the description doesn't disclose any behavioral traits such as authentication requirements, rate limits, pagination behavior, or what the return format looks like (e.g., list of file metadata). This leaves significant gaps for a tool with no structured safety hints.
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 at three words, front-loaded with the core action, and contains no wasted words. Every element ('List', 'task', 'attachments') directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is incomplete. It doesn't explain what the tool returns (e.g., attachment details, file types, sizes), behavioral constraints, or how it differs from sibling tools. For a read operation with no structured output documentation, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('task_id' and 'file_type_filter') fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List task attachments' clearly states the verb ('List') and resource ('task attachments'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ticktick_download_task_attachment' or 'ticktick_delete_task_attachment', which also involve task attachments but with different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'ticktick_download_task_attachment' (for downloading) and 'ticktick_delete_task_attachment' (for deletion), the agent receives no help in choosing between read-only listing and other attachment-related operations.
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 full burden but only states the basic operation. It lacks details on permissions, rate limits, pagination, error handling, or return format. For a read operation with no annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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 read tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'Get' entails (e.g., returns a list, includes metadata), behavioral constraints, or error cases. Given the complexity and lack of structured data, more context is needed.
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 100%, so the schema fully documents both parameters. The description implies tag-based filtering but adds no syntax, format, or usage details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Get all tasks with a specific tag' clearly states the verb ('Get') and resource ('tasks'), specifying filtering by tag. It distinguishes from general task-fetching tools but doesn't explicitly differentiate from similar filtering tools like 'ticktick_filter_tasks' or 'ticktick_search_tasks' in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'ticktick_filter_tasks' or 'ticktick_search_tasks', leaving the agent to infer usage 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 carries full burden. It states the action ('Get') but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what the output format looks like (e.g., list of tasks with details). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of task retrieval in a system with many sibling tools, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or how it integrates with other tools, leaving significant gaps for the agent to understand full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('days_ahead' and 'limit') clearly documented in the schema. The description adds no additional meaning beyond implying date-based filtering, so it meets the baseline of 3 where the schema does the heavy lifting without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('upcoming tasks'), specifying the scope ('within specified days'). It distinguishes from siblings like 'ticktick_get_today_tasks' by focusing on a future time window, though it doesn't explicitly mention how it differs from other task-retrieval tools like 'ticktick_filter_tasks' or 'ticktick_search_tasks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for task retrieval (e.g., 'ticktick_get_today_tasks', 'ticktick_get_overdue_tasks', 'ticktick_filter_tasks'), it lacks explicit context, prerequisites, or comparisons, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'generate' but doesn't clarify if this is a read-only operation (likely, given sibling patterns), what data sources it accesses, whether it requires authentication, or any rate limits. The term 'comprehensive' is vague and doesn't explain output format or depth. For a tool with 4 parameters and no annotations, this leaves significant 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 a single, efficient sentence with zero waste. It's front-loaded with the core action ('generate') and resource ('weekly productivity summary'), and the adjective 'comprehensive' adds useful context without verbosity. Every word earns its place in this minimal but informative statement.
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, nested objects, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'weekly productivity summary' contains, how it's formatted, whether it's textual or structured, or any prerequisites. For a tool generating a multi-section report with personalization options, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, providing good baseline documentation for parameters. The description adds no parameter-specific semantics beyond implying 'weekly' scope (covered by 'week_offset' in schema). It mentions 'comprehensive' but doesn't map to 'include_sections' or other parameters. With high schema coverage, the description doesn't compensate but doesn't detract, meeting the baseline.
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 'Generate comprehensive weekly productivity summary' clearly states the verb ('generate') and resource ('weekly productivity summary'), making the purpose evident. It distinguishes from siblings like 'ticktick_get_daily_focus_summary' by specifying 'weekly' scope, though it doesn't explicitly differentiate from other summary tools like 'ticktick_get_monthly_insights' beyond the time frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'ticktick_get_daily_focus_summary' or 'ticktick_get_monthly_insights' for different timeframes, or 'ticktick_get_productivity_report' for other report types. Usage context is implied only by the tool name and parameters, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'import' and 'bootstrap the task cache', implying a write operation that may affect data, but it doesn't disclose behavioral traits such as whether this is idempotent, what permissions are required, if it overwrites existing tasks, or how errors are handled. This is inadequate for a tool that likely modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an import tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like side effects, error handling, or what 'bootstrap the task cache' entails operationally. For a tool that likely involves data mutation, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'csv_data' fully described in the schema as 'CSV data with columns: task_id, project_id, title'. The description adds no additional meaning beyond this, such as format details or examples, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import tasks from CSV data') and the target ('to bootstrap the task cache'), providing a specific verb and resource. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_bulk_create_from_template' or 'ticktick_create_task', which might also create tasks, though the CSV focus is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'to bootstrap the task cache', which implies a use case for initializing or populating a cache, but it doesn't provide explicit guidance on when to use this tool versus alternatives like bulk creation tools or when not to use it (e.g., for incremental updates). No clear alternatives or exclusions are 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?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It implies a mutation (inviting changes project state) but doesn't disclose permission requirements, rate limits, whether invitations are revocable, or what happens if the user already has access. This leaves significant gaps for a tool that modifies collaboration settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase that front-loads the core purpose without unnecessary words. Every word earns its place, making it optimally concise for its limited content.
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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain behavioral aspects like permissions, side effects, or response format. Given the complexity of inviting collaborators (which involves access control and notifications), more context is needed beyond the basic purpose.
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 100%, so parameters are fully documented in the schema. The description adds no additional meaning about parameters beyond what's already in the schema (e.g., it doesn't explain role hierarchy or message formatting). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Invite user to project' clearly states the action (invite) and resource (user to project), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ticktick_share_project' or 'ticktick_set_project_permissions', which might involve similar collaboration functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing project access), exclusions (e.g., not for existing collaborators), or comparison to sibling tools like 'ticktick_share_project' or 'ticktick_remove_collaborator'.
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 full burden but provides minimal behavioral insight. 'Merge' implies a mutation, but it doesn't disclose effects like whether the source tag is deleted, tasks are reassigned, or if there are permission requirements. This leaves critical behavioral traits unspecified 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 a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's function, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain the merge outcome, error conditions, or side effects, leaving the agent with insufficient context to use the tool safely or 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 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying two tags are involved, which the schema already covers with 'source_tag_id' and 'target_tag_id'. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('merge') and resource ('two tags'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'ticktick_update_tag' or 'ticktick_delete_tag' by explaining what merging entails versus updating or deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if merging is preferred over deleting a tag and reassigning tasks, or how it relates to 'ticktick_bulk_tag_operations'. The description 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 full burden but offers minimal behavioral insight. It states the action is a 'move' (implying mutation), but doesn't disclose permissions required, whether the move is reversible, effects on project data, or error conditions (e.g., invalid IDs). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., permissions, side effects), usage context, and expected outcomes, leaving significant gaps for an AI agent to understand how to invoke it 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?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond implying 'project_id' and 'folder_id' are required for the move operation, which is already evident from the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and resource ('a project to a specific folder'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ticktick_reorder_projects' or 'ticktick_archive_project' that also modify project organization, leaving some ambiguity about when to choose this specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing existing project and folder IDs), exclusions (e.g., cannot move to non-existent folders), or related tools like 'ticktick_get_project_folders' for obtaining folder IDs, leaving usage context unclear.
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 full burden for behavioral disclosure. It states the action ('pause') but doesn't clarify if this is a read-only or destructive operation, what permissions are required, how it affects session state, or what happens on success/failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste. It's appropriately sized for a simple tool and front-loaded with the core action, making it highly efficient and easy to parse.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error conditions), usage context, and output expectations, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'session_id' parameter. The description adds no additional parameter semantics beyond what's in the schema, but with high coverage, the baseline is 3 as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('pause') and the resource ('current focus session'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'ticktick_stop_focus_session' or 'ticktick_resume_focus_session', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'stop_focus_session' or 'resume_focus_session'. It lacks context about prerequisites (e.g., needing an active session) or exclusions, offering only a basic statement of function.
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. 'Temporarily pause' implies a non-destructive, reversible mutation, but it doesn't disclose behavioral traits like whether it requires specific permissions, if it affects habit statistics or streaks, what happens if resumed later, or if there are rate limits. The description is minimal and lacks critical context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Temporarily pause a habit' is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no unnecessary elaboration.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral impact (e.g., how pausing affects habit tracking), error conditions, or return values. The schema covers parameters well, but overall context is insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (habit_id as 'ID of the habit to pause', resume_date as 'Date to resume (YYYY-MM-DD), optional'). The description adds no additional meaning beyond the schema, such as explaining what 'pause' entails or default behavior if resume_date is omitted. Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Temporarily pause a habit' clearly states the action (pause) and resource (habit) with the qualifier 'temporarily' indicating it's not permanent. It distinguishes from sibling tools like 'ticktick_delete_habit' (permanent removal) and 'ticktick_resume_habit' (resuming), but doesn't explicitly differentiate from 'ticktick_pause_recurring_task' or 'ticktick_pause_focus_session', which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., habit must exist), when not to use it (e.g., for permanent deletion), or direct alternatives like 'ticktick_resume_habit' for reversing the action. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states this is a manual registration for cache purposes but doesn't disclose behavioral traits like whether this is a read-only or write operation, what happens if the task ID already exists, how the cache is used, or any permissions required. The description is minimal and lacks critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for the tool's apparent complexity.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'register' entails operationally, how the cache works, what 'future reading' means, or what the tool returns. For a tool that likely modifies state (cache registration), more context is needed to guide safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain why task_id and project_id are required or how title enhances cache metadata). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('manually register') and resource ('task ID in the cache'), specifying it's for future reading. It distinguishes from siblings like ticktick_create_task by focusing on cache registration rather than task creation, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like ticktick_create_task or ticktick_get_cached_tasks. It mentions 'future reading' but gives no context about prerequisites, typical scenarios, 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?
No annotations are provided, so the description must fully convey behavioral traits. It states the action is to 'remove,' implying a mutation, but doesn't disclose whether this requires specific permissions, if the change is reversible, what happens if the tag doesn't exist, or any rate limits. The description is minimal and lacks critical behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core action, making it easy to parse and understand quickly. There is no wasted verbiage or structural issues.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances like idempotency. The lack of annotations means the description should compensate with more detail, but it fails to do so, leaving gaps in understanding the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions for 'task_id' and 'tag_name.' The description doesn't add any semantic details beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target ('a tag from a specific task'), making the purpose immediately understandable. It distinguishes from the sibling 'ticktick_add_tag_to_task' by specifying removal rather than addition, though it doesn't explicitly mention this contrast. The description avoids tautology by not just restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to remove a tag versus updating a task or using bulk operations. It doesn't mention prerequisites like needing an existing tag on the task or specify any context for usage, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Change project display order' implies a mutation operation, but it doesn't specify whether this requires specific permissions, if changes are reversible, what happens to other projects' orders, or if there are rate limits. For a mutation tool with zero annotation coverage, this leaves significant 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by directly conveying the tool's purpose.
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 (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks behavioral context (e.g., permissions, reversibility), usage guidelines, and any details about the expected outcome or error conditions. The schema covers parameters well, but the description fails to address other critical aspects for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. However, schema description coverage is 100% (the 'project_orders' parameter is fully described in the schema as 'Array of project IDs with their new sort orders'), so the baseline score of 3 applies. The description doesn't compensate but doesn't need to given the schema's completeness.
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 'Change project display order' clearly states the action (change) and resource (project display order), making the purpose immediately understandable. It distinguishes from siblings like 'ticktick_get_projects' (read) and 'ticktick_create_project' (create), though it doesn't explicitly differentiate from other project modification tools like 'ticktick_set_project_color'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing projects), when not to use it, or how it relates to similar tools like 'ticktick_move_project_to_folder' or 'ticktick_get_projects' for viewing order. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Resume') but doesn't clarify if this is a mutation (likely yes), what permissions are needed, whether it affects other sessions, or what happens upon success/failure (e.g., does it return session status?). For a tool that likely modifies state, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place by conveying essential information 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 is incomplete for a tool that likely performs a state change. It doesn't explain what 'resume' entails behaviorally (e.g., restarts timing, updates status), what the expected outcome is, or any error conditions. For a mutation tool with no structured support, this leaves critical gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'session_id' fully documented in the schema. The description adds no additional parameter context beyond implying a session must be paused, which is already inferred from 'resume a paused focus session'. This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resume') and resource ('a paused focus session'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'ticktick_start_focus_session' and 'ticktick_pause_focus_session' by specifying it's for resuming rather than starting or pausing. However, it doesn't explicitly mention what 'resume' entails (e.g., restarting a timer), which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a session must be paused first), exclusions (e.g., not for completed sessions), or related tools like 'ticktick_stop_focus_session'. The agent must infer usage from the name alone, which is insufficient for clear decision-making.
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 of behavioral disclosure. While 'resume' implies a state change (from paused to active), the description doesn't address permissions needed, whether the operation is reversible, what happens to habit tracking data, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'resuming' entails behaviorally, what the expected outcome is, or any error conditions. Given the complexity of state changes and the lack of structured data, more context is needed.
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 100%, with the single parameter 'habit_id' clearly documented in the schema. The description doesn't add any parameter details beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('resume') and target resource ('a paused habit'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling 'ticktick_pause_habit' or other habit-related tools, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., the habit must be paused), when not to use it, or what other tools might be relevant (like 'ticktick_pause_habit' or 'ticktick_update_habit').
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 full burden for behavioral disclosure. While 'Set' implies a write/mutation operation, it doesn't specify whether this requires authentication, what happens to existing goals, whether changes are reversible, or what the expected response looks like. For a mutation tool with zero annotation coverage, this represents a significant gap in behavioral 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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a tool with three parameters and gets straight to the point with zero wasted verbiage.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like authentication requirements, error conditions, or what constitutes a successful operation. While the schema covers parameters well, the overall context for proper tool invocation remains incomplete.
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 100%, with all three parameters well-documented in the schema itself. The description mentions 'daily or weekly' which aligns with the 'goal_type' parameter's description, but adds no additional semantic context beyond what the schema already provides. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('daily or weekly focus time goals'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'ticktick_set_habit_goal' or 'ticktick_set_task_estimate', but the focus on 'focus time goals' provides reasonable distinction within the context of the toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'ticktick_set_habit_goal' or other goal-setting tools. It doesn't mention prerequisites, dependencies, or typical use cases, leaving the agent with minimal context for appropriate tool selection.
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 of behavioral disclosure. 'Configure task recurrence' implies a mutation operation, but it doesn't specify whether this requires special permissions, whether it overwrites existing recurrence settings, what happens if the task doesn't exist, or what the response looks like (no output schema). For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 at just two words ('Configure task recurrence'), making it front-loaded and zero-waste. Every word earns its place by conveying the core functionality without unnecessary elaboration. This is an example of efficient communication where brevity doesn't sacrifice clarity of purpose.
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 mutation tool with complex nested parameters (recurrence_pattern with multiple sub-properties), no annotations, and no output schema, the description is inadequate. It doesn't explain the behavioral implications of configuring recurrence, doesn't provide usage context, and doesn't address the complexity of the recurrence_pattern object. The agent would need to rely heavily on the incomplete schema to understand how to use this 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 50%, meaning half the parameters lack schema descriptions. The tool description doesn't add any parameter-specific information beyond what's implied by 'Configure task recurrence' - it doesn't explain the structure of recurrence_pattern, the meaning of frequency values, or how end_condition works. Since the schema does provide some parameter documentation (task_id and frequency have descriptions), the baseline is 3, but the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configure task recurrence' clearly states the action (configure) and target (task recurrence), making the purpose immediately understandable. It distinguishes this tool from sibling tools like 'ticktick_create_task' or 'ticktick_update_task' by focusing specifically on recurrence settings rather than general task creation or modification. However, it doesn't explicitly mention that this applies to existing tasks (though the task_id parameter implies this).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., task must exist), when not to use it (e.g., for non-recurring tasks), or how it differs from similar tools like 'ticktick_update_task' which might also handle recurrence. The agent must infer usage solely from the tool name and parameters.
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 of behavioral disclosure. It states 'Set estimated time for a task', implying a mutation operation, but doesn't cover critical aspects like required permissions, whether the operation is idempotent, error conditions, or what happens if the task doesn't exist. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration. Every word earns its place.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral traits like side effects, error handling, or return values, leaving the agent with insufficient context to use the tool effectively. The high schema coverage helps with parameters but doesn't compensate for other gaps.
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 100%, so the schema already documents all three parameters with clear descriptions. The description doesn't add any additional meaning about the parameters beyond what's in the schema, such as explaining the relationship between 'estimated_minutes' and 'estimate_type'. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('estimated time for a task'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_update_task' or 'ticktick_set_recurring_task', which might also involve task modifications, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention if this is for initial estimation or updates, or how it relates to tools like 'ticktick_update_task' that might handle broader task modifications. This lack of context leaves the agent without usage direction.
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 full burden for behavioral disclosure. 'Share project with others' implies a mutation operation that grants access, but it doesn't specify whether this requires admin permissions, whether it sends notifications to recipients, what happens if emails are invalid, or if there are rate limits. The description is too minimal for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it immediately scannable 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?
For a mutation tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after sharing (e.g., confirmation, error handling), doesn't mention permissions requirements, and provides no behavioral context beyond the basic action. The 100% schema coverage helps with parameters but doesn't compensate for the lack of operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline expectation but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Share project with others' clearly states the action (share) and resource (project), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling tools like 'ticktick_invite_collaborator' or 'ticktick_set_project_permissions' that might handle similar sharing functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'ticktick_invite_collaborator' and 'ticktick_set_project_permissions' that might overlap in functionality, there's no indication of when this specific sharing tool is appropriate versus those other options.
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 full burden for behavioral disclosure. It states the action ('Stop') which implies a mutation, but doesn't clarify if this is destructive (e.g., ends tracking permanently), requires specific permissions, or has side effects like recording session data. The description lacks critical behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core action clearly, making it highly 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after stopping (e.g., does it save statistics, trigger notifications, or return confirmation?), nor does it address error conditions or behavioral nuances. Given the complexity of session management, more context is needed.
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 100% (the 'session_id' parameter is fully described in the schema), so the baseline is 3. The description adds no additional parameter information beyond what's already in the structured schema, maintaining this adequate but unenhanced level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the resource ('the current focus session'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'ticktick_pause_focus_session' or 'ticktick_resume_focus_session', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like pausing or resuming a focus session. There's no mention of prerequisites (e.g., must have an active session) or context for when stopping is appropriate versus other operations.
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. 'Restore' implies a mutation (changing project state from archived to active), but it doesn't disclose permissions needed, whether it's reversible (can be re-archived), side effects (e.g., tasks become visible again), or error conditions (e.g., invalid project_id). Minimal behavioral context is given beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single sentence 'Restore an archived project' that directly states the purpose. No wasted words or unnecessary elaboration. Perfectly front-loaded and appropriately sized for a simple tool.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (permissions, reversibility), usage context (prerequisites, alternatives), and expected outcomes (what happens after restoration). The high schema coverage helps with parameters, but overall context is insufficient.
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 100% (parameter 'project_id' is fully described in schema as 'ID of the project to unarchive'). The description adds no additional parameter information beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Restore an archived project' clearly states the action (restore/unarchive) and the resource (project). It distinguishes from siblings like 'ticktick_archive_project' by indicating the opposite operation. However, it doesn't specify what 'restore' entails (e.g., returning to active projects list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., project must be archived), exclusions, or related tools like 'ticktick_get_projects' to check archive status. The description implies usage only for archived projects but doesn't state this explicitly.
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 of behavioral disclosure. It states 'Update an existing habit' which implies a mutation operation, but it doesn't specify what happens on update (e.g., partial vs. full updates, error handling, or side effects). This is inadequate for a mutation tool with zero annotation coverage, as it lacks details on permissions, reversibility, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Update an existing habit.' It is front-loaded with the core action and resource, with no wasted words or unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (mutation with 6 parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain behavioral traits, return values, or usage context, leaving significant gaps for an AI agent to understand how to invoke it correctly beyond basic purpose.
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 100% description coverage, with each parameter clearly documented (e.g., 'ID of the habit to update'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing habit' clearly states the action (update) and resource (habit), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ticktick_update_task' or 'ticktick_update_tag', which follow the same pattern for different resources, so it misses the highest score for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., habit must exist), exclusions, or comparisons to related tools like 'ticktick_create_habit' or 'ticktick_delete_habit', leaving the agent without context for selection.
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 full burden but offers minimal behavioral insight. It states 'Configure' which implies a write/mutation operation, but doesn't disclose whether this requires specific permissions, if changes are immediate or batched, what happens to unspecified settings (partial vs full updates), or error conditions. The description adds little beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (success confirmation, updated settings object, or nothing), doesn't mention authentication requirements or rate limits, and provides no guidance on partial versus complete updates. The schema handles parameter documentation well, but behavioral context is lacking.
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 100%, with detailed parameter descriptions in the schema itself. The description adds no additional parameter semantics beyond implying 'various events' maps to the nested notification categories. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Configure') and resource ('notification preferences for various events'), making the purpose understandable. It doesn't explicitly distinguish from sibling tools like 'ticktick_update_user_settings' or 'ticktick_get_notification_settings', but the specificity of 'notification preferences' provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites (like needing to fetch current settings first), nor comparison to related tools such as 'ticktick_get_notification_settings' or 'ticktick_update_user_settings' that might handle similar functionality.
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 of behavioral disclosure. 'Configure' implies a mutation operation, but the description doesn't specify whether this requires special permissions, if changes are reversible, potential side effects (e.g., data loss during sync), or rate limits. For a tool that likely modifies system settings, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Configure synchronization behavior and preferences') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it easy to parse quickly.
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 complexity of a configuration tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as permission requirements, behavioral traits (e.g., whether it's idempotent), or what the tool returns upon success/failure. While the schema covers parameters well, the overall tool behavior remains underspecified for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, thoroughly documenting all parameters and nested properties (e.g., 'sync_frequency' enum values, 'data_types' options). The description adds no additional parameter semantics beyond the schema, but since the schema is comprehensive, a baseline score of 3 is appropriate as it doesn't need to compensate for gaps.
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 'Configure synchronization behavior and preferences' clearly states the verb ('configure') and resource ('synchronization behavior and preferences'), making the purpose evident. However, it doesn't explicitly distinguish this tool from sibling tools like 'ticktick_sync_with_google_calendar' or 'ticktick_get_sync_settings', which handle specific sync operations or retrieval rather than configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin access), compare it to sibling tools like 'ticktick_get_sync_settings' for viewing settings or 'ticktick_sync_with_google_calendar' for external syncs, or specify use cases (e.g., initial setup vs. adjustments). This lack of context leaves the agent guessing.
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 full burden but offers minimal behavioral insight. It implies a mutation operation ('Update') but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what happens to unspecified fields (e.g., partial updates). This leaves significant gaps for a tool that modifies data.
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, direct sentence with zero waste—'Update an existing task' is front-loaded and efficiently conveys the core action. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (mutation with 6 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like error handling, response format, or usage context, leaving the agent under-informed for safe and effective invocation.
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 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond the schema, such as explaining parameter interactions (e.g., setting 'completed' to true might override other fields) or format details for 'due_date'. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing task'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ticktick_update_task_note' or 'ticktick_update_task_template', which also update task-related entities, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing task ID), exclusions, or compare to siblings like 'ticktick_complete_task' for marking completion or 'ticktick_assign_task' for assignment changes.
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 of behavioral disclosure. 'Attach files to tasks' implies a write/mutation operation, but it doesn't specify permissions required, rate limits, whether attachments are permanent or reversible, or what happens on success/failure (e.g., returns an attachment ID). This leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Attach files to tasks'), making it immediately scannable and easy to parse. Every word earns its place.
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 complexity of a file upload operation with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks context on behavioral aspects (e.g., mutation effects, error handling), usage guidelines, and output details. For a tool that modifies task state, this minimal description leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all 5 parameters (e.g., 'Base64 encoded file data', 'MIME type of the file'). The description adds no additional parameter semantics beyond what the schema provides, such as file size limits or supported MIME types. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Attach files to tasks' clearly states the verb ('attach') and resource ('files to tasks'), making the purpose immediately understandable. It distinguishes from siblings like 'ticktick_download_task_attachment' (download vs. upload) and 'ticktick_delete_task_attachment' (delete vs. attach), but doesn't explicitly differentiate from other file-related operations in the context of 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., task must exist), constraints (e.g., file size limits), or related tools like 'ticktick_get_task_attachments' for viewing attachments. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Create' which implies a write operation, but doesn't disclose behavioral traits like whether it requires specific permissions, what happens on success/failure, if it's idempotent, or any rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple creation tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is minimal but functional. It states the purpose clearly, but lacks behavioral context and usage guidance. Given the complexity (5 parameters, mutation operation), it should do more to compensate for the missing structured data.
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 100%, so the schema fully documents all 5 parameters. The description adds no parameter information beyond what's in the schema, which meets the baseline for high coverage but doesn't provide additional context like examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new habit in TickTick'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'ticktick_create_task' or 'ticktick_create_project', which also create resources in the same system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when not to use it, or how it relates to sibling tools like 'ticktick_update_habit' or 'ticktick_delete_habit'.
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 of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or the format of returned statistics. This leaves gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly. Every word contributes directly to the 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?
For a simple read operation with one parameter and no output schema, the description is minimally adequate. However, it lacks details on what specific statistics are returned (e.g., completion rates, longest streak) and how they're structured, which would be helpful given the absence of an output schema. The context signals indicate low complexity, but more completeness could enhance usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'habit_id' fully documented in the schema. The description doesn't add any additional meaning beyond the schema, such as examples of valid IDs or context about where to obtain them. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('habit statistics and streaks'), making the purpose evident. It distinguishes from some siblings like 'ticktick_get_habits' (which lists habits) and 'ticktick_get_habit_streaks' (which might focus only on streaks), but the distinction could be more explicit regarding what specific statistics are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to choose this over 'ticktick_get_habit_streaks' or 'ticktick_get_habits_summary', nor does it specify prerequisites like needing a valid habit ID. The description lacks context for decision-making.
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 of behavioral disclosure. It states it's a read operation ('Get'), implying it's non-destructive, but doesn't cover aspects like authentication needs, rate limits, error conditions, or the format of returned data (e.g., numeric values, timestamps). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits and usage context. Without annotations or output schema, it should ideally provide more guidance on what the tool returns or when to use it, but it's not completely inadequate.
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 100%, with the single parameter 'habit_id' fully documented in the schema as 'ID of the habit'. The description doesn't add any extra meaning beyond this (e.g., where to find the ID, format examples), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current and longest streaks for a habit', making the purpose specific and understandable. It distinguishes itself from siblings like 'ticktick_get_habits' (which lists habits) or 'ticktick_get_habit_stats' (which might provide broader statistics), but doesn't explicitly contrast with them, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing habit), exclusions, or comparisons to similar tools like 'ticktick_get_habit_stats' or 'ticktick_get_habit_history', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get'), which implies non-destructive behavior, but doesn't mention authentication needs, rate limits, response format, or whether it returns real-time or cached data. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple read operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 2 well-documented parameters and no output schema, the description is minimally adequate but incomplete. It lacks information about return values, authentication requirements, and behavioral context that would help an agent use it effectively. The absence of annotations increases the need for descriptive 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 100%, so the schema fully documents both parameters. The description adds no parameter-specific information beyond what's already in the schema (category filtering and disabled notifications inclusion). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current notification preferences and settings'), making the purpose immediately understandable. It doesn't explicitly differentiate from its sibling 'ticktick_update_notification_settings', but the 'Get' vs 'Update' distinction is implied through contrasting verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'ticktick_update_notification_settings' for modifying settings, nor does it explain prerequisites like authentication requirements or context for accessing notification preferences.
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 of behavioral disclosure. It mentions 'comprehensive productivity analytics and insights', which implies a read-only operation, but does not specify data scope (e.g., user-specific vs. team-wide), authentication needs, rate limits, or output format. For a tool with no annotations, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('Get') and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a productivity analytics tool with 6 parameters and no output schema, the description is minimally adequate. It states the purpose but lacks details on behavioral traits, usage context, and output structure. With no annotations and an incomplete picture of what 'insights' entail, it leaves the agent with gaps, though the schema provides good parameter coverage.
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 100% description coverage, clearly documenting all 6 parameters with enums and defaults. The description adds no additional parameter semantics beyond the schema, such as explaining interactions between parameters (e.g., 'start_date' and 'end_date' only apply when 'time_range' is 'custom'). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'comprehensive productivity analytics and insights', which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'ticktick_get_productivity_insights' or 'ticktick_get_completion_trends', which might offer similar or overlapping functionality, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to productivity and analytics (e.g., 'ticktick_get_productivity_insights', 'ticktick_get_completion_trends'), there is no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description doesn't specify whether this requires authentication, what format the tasks are returned in, if there are rate limits, or if it includes completed tasks. For a retrieval tool with zero annotation coverage, this leaves significant 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it doesn't provide enough context about behavioral aspects like authentication needs, return format, or error handling, which are important for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'include_overdue' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tasks scheduled for today' clearly states the verb ('Get') and resource ('tasks scheduled for today'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from similar sibling tools like 'ticktick_get_overdue_tasks' or 'ticktick_get_upcoming_tasks', which would require mentioning the specific time scope of 'today' as the distinguishing factor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for task retrieval (e.g., 'ticktick_get_overdue_tasks', 'ticktick_get_upcoming_tasks', 'ticktick_filter_tasks'), there's no indication of when 'today' is the appropriate filter versus other time-based or filtered queries.
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 full burden for behavioral disclosure. 'Set or update habit goal' implies a mutation operation but provides no information about permissions required, whether changes are reversible, what happens to existing goal settings, or what the response looks like. For a tool that modifies data with no annotation coverage, this represents a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with just four words that directly convey the core functionality. There's zero wasted language, and the structure is front-loaded with the essential action. Every word earns its place in this minimal but complete phrase.
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?
For a mutation tool with no annotations and no output schema, the description provides the minimum viable information about what the tool does. While concise and clear about purpose, it lacks important context about behavioral implications, usage scenarios, and expected outcomes. The 100% schema coverage helps with parameters, but overall completeness is just adequate for basic understanding.
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 100%, so the schema already fully documents all four parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate coverage when the schema does the heavy lifting, though the description could have explained relationships between parameters like how goal_type affects target_count interpretation.
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 'Set or update habit goal' clearly states the action (set/update) and resource (habit goal), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'ticktick_update_habit' or 'ticktick_set_focus_goals', which could cause confusion about when to use this specific habit goal tool versus other habit-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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'ticktick_update_habit' and 'ticktick_set_focus_goals' available, the agent receives no indication about whether this is the primary way to modify habit goals, if it's for initial setup versus ongoing adjustments, or how it differs from general habit updates.
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 of behavioral disclosure. It states 'modify' which implies a write/mutation operation, but doesn't mention whether this requires specific permissions, if changes are reversible, what happens to unspecified settings, or error conditions. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the tool's purpose without unnecessary words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point.
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?
For a mutation tool with no annotations and no output schema, the description is minimally adequate. It identifies the tool's purpose but leaves significant gaps: no behavioral context (permissions, side effects), no usage guidance, and no information about return values. The comprehensive schema documentation prevents a lower score, but the description should do more given the mutation nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'user preferences and account settings' which aligns with the 'settings' object parameter, but adds no specific details beyond what the schema provides. With 100% schema description coverage that thoroughly documents all 9 nested properties, the description provides minimal additional value. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 'Modify user preferences and account settings' clearly states the action (modify) and resource (user preferences/account settings). It distinguishes itself from sibling tools like ticktick_update_notification_settings or ticktick_update_sync_settings by focusing on general user settings rather than specific notification or sync configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication requirements), whether it applies to the current user or other users, or how it differs from related settings tools like ticktick_update_notification_settings. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify whether this requires authentication, what format the data returns in, whether there are rate limits, or if the operation is paginated. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just four words ('Get all project folders and groups'). It's front-loaded with the core action and resource, with zero wasted words. Every element serves a clear purpose in communicating 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?
For a simple read operation with no parameters and no output schema, the description provides the minimum viable information about what the tool does. However, without annotations or output schema, it should ideally mention something about the return format or data structure. The description is adequate but leaves the agent to discover behavioral details through trial.
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 with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the operation itself. This meets the baseline expectation for parameter-less tools.
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 'Get all project folders and groups' clearly states the verb ('Get') and resource ('project folders and groups'), making the purpose immediately understandable. It distinguishes from siblings like 'ticktick_get_projects' by specifying folders and groups rather than projects themselves. However, it doesn't fully explain what 'groups' refers to in the context of TickTick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this operation is appropriate, or how it differs from related tools like 'ticktick_get_projects' or 'ticktick_get_project_templates'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get all tags' but doesn't disclose behavioral traits such as whether it requires authentication, rate limits, pagination, sorting, or what the return format looks like (e.g., list of tag objects). For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get all tags from TickTick.' It is front-loaded with the core action and resource, with zero wasted words. Every part of the sentence directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description is minimally adequate. It states what the tool does but lacks context on behavior (e.g., authentication, return format) and usage guidelines. For a simple read tool, it meets basic needs but could be more informative about output and operational constraints.
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 parameters with 100% coverage, so no parameters need documentation. The description doesn't add param info, which is fine here. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs, and the description doesn't need to compensate.
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 'Get all tags from TickTick' clearly states the verb ('Get') and resource ('tags'), specifying it retrieves all tags. It distinguishes from siblings like 'ticktick_get_tag_usage_stats' or 'ticktick_get_tasks_by_tag' by focusing on tags themselves, not usage or tasks. However, it doesn't explicitly differentiate from 'ticktick_create_tag' or 'ticktick_update_tag', though those are clearly mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare to other tag-related tools like 'ticktick_get_tag_usage_stats' for statistics, or indicate if it's for listing tags before operations like adding tags to tasks. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/liadgez/ticktick-mcp-server'

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