Todoist MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation2/5
Multiple tools have overlapping purposes, causing confusion. For example, there are three separate search tools (search_tasks, search_tasks_using_and, search_tasks_using_or) that could be consolidated, and several 'list_' tools (e.g., list_brian_time_sensitive_tasks, list_becky_time_sensitive_tasks) are very similar in function but differ only by user or filter. This overlap makes it difficult for an agent to choose the right tool without deep context.
Naming Consistency3/5The naming is mixed but somewhat readable. Most tools use snake_case and start with verbs like 'get_', 'list_', 'create_', 'update_', 'complete_', which is consistent. However, there are inconsistencies such as 'complete_becky_task' vs. 'complete_task' (one is specific, the other general) and 'search_tasks' vs. 'search_tasks_using_and' vs. 'search_tasks_using_or' (redundant naming). Overall, the pattern is discernible but not fully uniform.
Tool Count2/5With 33 tools, the count is excessive for a Todoist server, indicating poor scoping. Many tools are highly specific (e.g., get_chores_due_today, get_tickler_tasks) and could be generalized into fewer, more flexible tools. This bloated set increases complexity and reduces usability, as agents must navigate numerous similar tools for basic operations.
Completeness4/5The tool surface covers core Todoist operations well, including CRUD for tasks (create, update, complete, uncomplete), project and label management, and various querying functions. However, there are minor gaps, such as no direct tool for deleting tasks or managing project settings beyond labels, which might require workarounds but doesn't severely hinder functionality.
Average 3.7/5 across 33 of 33 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits like whether completion is reversible, if it requires specific permissions, what happens to task data, or if there are side effects. For a mutation tool with zero 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/5Is 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-loaded with the core action, 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/5Given 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 multiple sibling tools, the description is incomplete. It doesn't explain the outcome, return values, or how it differs from similar operations like 'uncomplete_task'. The agent lacks sufficient context to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'task_id' documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Complete a task by its ID' clearly states the action (complete) and target (task), but it's vague about what 'complete' means in this context. It doesn't distinguish from siblings like 'uncomplete_task' or 'update_task', leaving ambiguity about whether this is a status change, archival, or deletion 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/5Does 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 'uncomplete_task', 'update_task', and 'move_task', the description offers no context about prerequisites, when this operation is appropriate, or what happens after completion.
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 'Get projects', suggesting a read-only operation, but doesn't specify if this requires authentication, what the return format looks like, or any rate limits. The description lacks details on behavioral traits like pagination, error handling, or data freshness, which are critical for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose, but it's somewhat wordy and ambiguous with phrases like 'ballpark' and 'per Brian'. It could be more front-loaded and precise. While not excessively long, it doesn't maximize clarity per word, and the structure could be improved for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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., project details, list format) or any behavioral aspects like error conditions. For a tool with no structured data to rely on, the description should provide more context about the operation and results, but it falls short, 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any gaps, and it appropriately doesn't discuss parameters. A baseline of 4 is applied since no parameter information is required, and the description doesn't add unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves projects belonging to Becky that are shared for tasks in her domain, which provides a basic purpose. However, it's somewhat vague about what 'ballpark' and 'per Brian' mean operationally, and it doesn't clearly differentiate from sibling tools like 'get_brian_shared_projects' or 'list_gtd_projects' in terms of scope or filtering criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Becky's shared projects but offers no explicit guidance on when to use this tool versus alternatives like 'get_brian_shared_projects' or 'list_gtd_projects'. There's no mention of prerequisites, exclusions, or specific contexts where this tool is preferred, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Get projects' which suggests a read operation, but doesn't specify if it's safe, requires permissions, has rate limits, or what the return format might be. The description adds minimal context beyond the basic action, failing to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is somewhat wordy and unclear ('in his ballpark to handle per Becky'), which could be more concise. It front-loads the purpose but includes ambiguous phrasing that doesn't earn its place efficiently. It's not overly verbose but lacks polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 simple tool with 0 parameters, the description is incomplete. It fails to explain what 'shared projects' means, how they are returned, or any behavioral traits. For a tool with no structured data, the description should provide more context to be fully helpful to an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves projects belonging to Brian that are shared for tasks in his ballpark, which provides a vague purpose. However, it lacks specificity about what 'ballpark' means or what 'shared for tasks' entails, making it somewhat ambiguous. It distinguishes from siblings like 'get_brian_only_projects' by mentioning 'shared' but doesn't clearly differentiate from 'get_becky_shared_projects' beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing Brian's shared projects for tasks in his ballpark, but provides no explicit guidance on when to use this tool versus alternatives like 'get_brian_only_projects' or 'get_becky_shared_projects'. There are no exclusions, prerequisites, or clear context for selection, leaving the agent to infer usage based on the vague 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates a task but doesn't mention authentication requirements, rate limits, whether the task becomes immediately active, what happens on duplicate titles, or what the return value looks like (since no output schema exists). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that efficiently communicates the core functionality and key parameter information. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 happens after creation, error conditions, authentication needs, or how this differs from similar tools. Given the complexity of task management and rich sibling toolset, more contextual information would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 6 parameters thoroughly. The description lists the same parameters (title, description, project, labels, priority, due date) but doesn't add meaningful semantic context beyond what's in the schema. The 'Only title is required' statement is useful but already implied by the schema's required array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new Todoist task') along with the key fields that can be set. It distinguishes from siblings like 'update_task' by specifying creation rather than modification. However, it doesn't explicitly differentiate from other creation tools like 'create_project_label' 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/5Does 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 'create_task_comment' or 'create_project_label'. It mentions that 'Only title is required', which is a basic parameter requirement but doesn't help the agent choose between this and other task-related tools in the sibling list.
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 'Move a task' but doesn't mention permissions needed, whether the move is reversible, effects on task metadata, or error conditions. 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/5Is 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'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/5Given 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 cover behavioral aspects like permissions, side effects, or return values, leaving gaps that could hinder an AI agent's correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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, so the baseline is 3. The tool description adds no additional meaning beyond the schema, such as explaining format constraints or relationships between parameters, but doesn't detract from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and the resource ('a task from one project to another'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_task' or 'create_task', which could 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/5Does 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 'update_task' for other task modifications or 'create_task' for new tasks. It lacks explicit context or exclusions, leaving usage unclear relative to siblings.
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 (reopening) but doesn't disclose permissions needed, whether the operation is reversible, error conditions (e.g., invalid ID), or side effects. The phrase 'uncomplete (reopen)' suggests it changes task status, but lacks details on what 'reopen' entails practically.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded in a single, efficient sentence. Every word earns its place by specifying the action and target, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 'reopen' means behaviorally (e.g., sets status to incomplete, updates timestamps), what the tool returns, or error handling. Given the complexity of task management and rich sibling tools, 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'task_id' clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, such as ID format or validation rules. Baseline 3 is appropriate since the schema fully covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('uncomplete/reopen') and resource ('a task by its ID'), making the purpose immediately understandable. It distinguishes itself from 'complete_task' by specifying the opposite operation, though it doesn't explicitly mention sibling tools like 'update_task' which might also modify task status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., task must be completed first), compare to sibling tools like 'update_task' for status changes, or specify contexts where reopening is appropriate versus creating a new task.
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 'Get' which implies a read operation, but doesn't specify if it requires authentication, returns a specific format, has rate limits, 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/5Is 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. It's front-loaded with the action and resources, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It specifies what projects are retrieved, which is essential, but lacks details on return format, error handling, or integration context, leaving some gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate as it doesn't have to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resources ('the three inbox projects'), listing them explicitly: Inbox, Brian inbox - per Becky, and Becky inbox - per Brian. It distinguishes from siblings like 'get_becky_shared_projects' or 'get_brian_only_projects' by focusing on inbox projects, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., for inbox management vs. other project types), or exclusions, leaving the agent to infer usage from the name and sibling tools 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 the return format ('structured JSON data') and some fields included, which adds value. However, it lacks details on permissions, rate limits, error handling, or whether it's a read-only operation (implied by 'Get' but not confirmed). For a 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that efficiently convey the core action and return details without any fluff. It's front-loaded with the main purpose and follows up with useful return information. Every sentence earns its place by adding value, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers the purpose and return format, which is sufficient for a basic read operation. However, without annotations or output schema, it could benefit from more behavioral context (e.g., read-only confirmation, error cases) to be fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Since there are no parameters to explain, the baseline is 4, as the description doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all tasks from the "Shopping list" project in Todoist'), making the purpose specific and understandable. It distinguishes itself from siblings by focusing on a specific project rather than general task retrieval or other operations. However, it doesn't explicitly contrast with similar tools like 'get_tasks_with_label' or 'search_tasks', which slightly limits 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/5Does 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., 'get_tasks_due_tomorrow', 'search_tasks'), there's no indication of when this specific project-focused tool is preferred, nor any prerequisites or exclusions mentioned. Usage is implied by the project name 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?
No annotations are provided, so the description carries the full burden. It mentions that the tool updates tasks and that fields are optional, but lacks details on permissions required, whether updates are reversible, rate limits, error handling, or what the response looks like. For a mutation tool with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a clarifying note on optional fields. Every sentence earns its place with no wasted words, 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/5Given 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 cover behavioral aspects like side effects, error cases, or response format, leaving gaps that could hinder an AI agent's ability to use the tool correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 thoroughly (e.g., 'task_id' as required, 'priority' as 1-4). The description adds minimal value by listing the updatable fields and noting they are optional, but doesn't provide additional semantics beyond what's in 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update a Todoist task') and specifies the fields that can be modified ('new title, description, labels, priority, or due string'). It distinguishes from sibling tools like 'create_task' by focusing on updates rather than creation, though it doesn't explicitly differentiate from similar update operations like 'move_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when modifying existing tasks and mentions that 'All fields are optional - only provided fields will be updated,' which provides some context on how to use it. However, it doesn't explicitly state when to choose this tool over alternatives like 'complete_task' or 'move_task,' nor does it mention prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a write operation ('Create') and mentions the automatic signature addition, which is useful behavioral context. However, it doesn't cover important aspects like authentication requirements, error conditions, rate limits, or what happens if the task ID is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that states exactly what the tool does with no wasted words. It's front-loaded with the core functionality and includes the important behavioral detail about the automatic signature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no annotations and no output schema, the description is somewhat incomplete. It covers the basic action and one behavioral trait (signature), but lacks information about return values, error handling, and operational constraints that would be important for an agent 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear parameter documentation, so the description doesn't need to add parameter semantics. The description doesn't provide any additional parameter information beyond what's in the schema, which is acceptable given the comprehensive schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new comment') and target resource ('on a specific Todoist task'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'get_task_comments' beyond the obvious create vs. get distinction, so it doesn't fully address potential confusion with related 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/5Does 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), when not to use it, or how it relates to sibling tools like 'get_task_comments' or 'update_task' for comment management.
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. It describes the mutation actions (setting due date, adding comment, moving), but lacks details on permissions needed, whether changes are reversible, error conditions, or what the response looks like. For a mutation tool 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists key actions without unnecessary words. Every part earns its place by specifying the task type and completion steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 one parameter, the description covers the basic purpose and actions but lacks behavioral context like side effects, return values, or error handling. It's minimally viable but has clear gaps for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'task_id', which the schema describes as 'The ID of the task to complete'. The description doesn't add parameter details beyond this, but with high coverage and only one parameter, a baseline of 4 is appropriate as the schema adequately documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Complete a Brian shared task') and specifies the resource ('assigned to Brian from Becky'), with details on what completion entails (setting due date, adding comment, moving to project). It distinguishes from 'complete_task' by specifying it's for 'Brian shared tasks' from Becky, though not explicitly contrasting with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tasks 'assigned to Brian from Becky' and moving to 'Becky inbox project', providing some context. However, it lacks explicit guidance on when to use this vs. alternatives like 'complete_task' or 'move_task', and no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the return format ('structured JSON data') and some fields, but lacks details on permissions, rate limits, pagination, or error handling. For a read operation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose and source, the second details the return data. It's front-loaded with the core function and efficiently lists key fields without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 0 parameters and no output schema, the description covers the purpose and return format adequately. However, without annotations or output schema, it lacks details on response structure (e.g., array format) and behavioral constraints, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'tasks from the Areas of focus project in Todoist', specifying the source and type of data. It distinguishes from siblings by targeting a specific project rather than general task retrieval, though it doesn't explicitly name alternatives like 'get_tasks_due_this_week'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when tasks from the 'Areas of focus' project are needed, but doesn't provide explicit guidance on when to use this tool versus other task-retrieval siblings (e.g., 'get_tasks_due_tomorrow' or 'search_tasks'). 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 the full burden of behavioral disclosure. It indicates a read operation ('Get') but doesn't specify return format, pagination, error conditions, or any behavioral traits like rate limits or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond the 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/5Is 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's front-loaded with the core action and immediately specifies the key constraints ('only to Brian' and 'NOT shared'), making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate for conveying the basic purpose. However, it lacks details on return values, error handling, or behavioral context, which could be important for an AI agent to use it correctly. It's minimally viable but leaves room for more completeness in a real-world scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 are documented in the schema. The description doesn't need to add parameter details, and it appropriately focuses on the tool's purpose without unnecessary parameter explanations. This meets the baseline for tools with no parameters, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get projects') and specifies the resource scope ('that belong only to Brian and are NOT shared'), which distinguishes it from general project retrieval tools. However, it doesn't explicitly differentiate from sibling tools like 'get_brian_shared_projects' or 'list_gtd_projects' beyond the 'only Brian' and 'NOT shared' qualifiers, making it clear but not fully sibling-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'only to Brian and are NOT shared', suggesting it's for retrieving Brian's private projects. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_brian_shared_projects' or 'list_gtd_projects', and provides no exclusions or prerequisites, leaving usage somewhat inferred rather than clearly 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('structured JSON data with comment details'), which adds some context, but it does not cover important aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or pagination. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and return data. It is front-loaded with the main action and resource, followed by details on the output, with no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and high schema coverage, the description is adequate but incomplete. It lacks an output schema, and with no annotations, it should provide more behavioral context (e.g., read-only nature, error cases). The description covers the basics but misses details needed for full understanding in the absence of structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the single parameter 'task_id'. The description does not add any parameter-specific details beyond what the schema provides (e.g., no examples or format clarifications). According to the rules, when schema coverage is high (>80%), the baseline score is 3, as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all comments') and resource ('for a specific Todoist task'), distinguishing it from sibling tools like 'create_task_comment' (which creates comments) and 'get_tasks_due_tomorrow' (which retrieves tasks). It precisely defines the scope as retrieving all comments for a given task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when comments for a specific task are needed, but it does not explicitly state when to use this tool versus alternatives (e.g., no mention of other comment-related tools or task retrieval tools). It provides basic context but lacks explicit guidance on exclusions or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool creates a label with a fixed charcoal color, which is useful behavioral context. However, it does not mention permissions, rate limits, or what happens on failure (e.g., duplicate names), leaving gaps in transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by specific constraints (naming rule and color). Both sentences are essential—the first states the purpose, and the second adds critical behavioral details—with no wasted words, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 no annotations and no output schema), the description covers the creation action, naming rule, and color, but lacks information on return values, error handling, or system-level behaviors. It is adequate for basic use but incomplete for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by reinforcing the naming requirement ('must start with "PROJECT: "') and providing an example, which clarifies semantics beyond the schema's basic description. This extra guidance justifies a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new project label'), the target resource ('in Todoist'), and distinguishes it from siblings by focusing on label creation rather than tasks or other operations. It specifies the unique naming convention and color, making the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating project labels in Todoist with specific formatting, but does not explicitly state when to use this tool versus alternatives (e.g., other label-related tools if they existed) or mention prerequisites. It provides context but lacks explicit guidance on exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns structured JSON data with specific task details, which is useful behavioral context. However, it does not mention potential limitations like pagination, rate limits, or authentication needs, leaving some behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: one stating the purpose and exclusions, and another detailing the return format. It is front-loaded with key information, though the second sentence could be slightly more concise by integrating return details more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (filtering tasks by label with exclusions), no annotations, and no output schema, the description does a good job by specifying exclusions and return data. However, it could be more complete by mentioning error cases or response structure details, which would help in a no-annotation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter ('label'), so the schema already documents it well. The description does not add any additional meaning or syntax details beyond what the schema provides, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all tasks with a specific label'), and distinguishes from siblings by specifying exclusions ('not part of the "Brian projects" or "Projects" projects'). It also mentions the return format, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (for tasks with a specific label, excluding certain projects), but does not explicitly mention when not to use it or name alternative tools. This gives good guidance but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns structured JSON data with specific task details, which is useful behavioral context. However, it does not mention potential limitations like rate limits, authentication needs, or pagination behavior, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the action and filter, and the second details the return data. Every sentence adds value without redundancy, making it front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description provides sufficient context by specifying the filter and return format. It covers the essential aspects for a read operation, though it could be more complete by mentioning authentication or rate limits, but this is minor given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description appropriately does not add parameter information, maintaining focus on the tool's purpose and output. A baseline of 4 is applied as it compensates adequately for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all waiting tasks'), resource ('from Todoist'), and scope ('using the filter "#Waiting | #Brian waiting | #Ansonia Waiting"'), distinguishing it from sibling tools like get_tasks_due_today or get_tasks_with_label by focusing on a specific filter-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the filter criteria, but does not explicitly state when to use this tool versus alternatives like search_tasks or get_tasks_with_label. It provides some guidance through the filter details but lacks explicit comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('structured JSON data') and enumerates the data fields included, which is valuable behavioral information. However, it doesn't mention potential limitations like pagination, rate limits, authentication requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: one stating the action and source, another detailing the return format. Every element serves a purpose with no redundant information, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no parameters and no output schema, the description provides good coverage: it specifies the exact data source, filter criteria, and return data structure. The main gap is lack of information about potential constraints (pagination, rate limits) that would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool does and returns. This meets the baseline expectation for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all Becky inbox per Brian tasks'), source system ('from Todoist'), and filter criteria ('using the ##Becky inbox - per Brian filter'). It distinguishes itself from sibling tools like 'list_brian_inbox_per_becky_tasks' by specifying the exact user perspective and filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning the specific filter, but doesn't explicitly state when to use this tool versus alternatives like 'list_personal_inbox_tasks' or 'get_tasks_with_label'. It provides some guidance through the filter specification but lacks explicit comparison or exclusion statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('structured JSON data with task details') and some behavioral aspects (exclusion of project categories), but doesn't mention pagination, rate limits, authentication requirements, error handling, or what 'excluding various project categories' specifically means. It provides basic context but lacks comprehensive behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose with key constraints, and the second describes the return format. Every element adds value without redundancy, making it appropriately concise and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters (simplifying input) but no output schema (requiring description to explain returns), the description adequately covers the return format. However, as a read operation with no annotations, it could benefit from more behavioral context like error cases or data freshness. It's minimally complete but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and behavior. This meets the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('tasks due this week from Todoist'), specifies the time scope ('next 7 days'), and distinguishes it from siblings by mentioning exclusion criteria ('excluding various project categories'). It provides specific differentiation from tools like get_tasks_due_tomorrow or get_tasks_with_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use it ('tasks due this week'), but doesn't explicitly state when not to use it or name specific alternatives. It implies usage for weekly due tasks but lacks explicit exclusions or comparisons to siblings like get_tasks_due_tomorrow or search_tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the operation (fetching data), the source (Todoist), the filter logic, and the return format. However, it doesn't mention potential limitations like rate limits, authentication requirements, error conditions, or whether the data is cached/live. For a read-only tool with zero annotation coverage, this is adequate but leaves 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the purpose, filter logic, and return format without any wasted words. It's front-loaded with the core action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters), lack of annotations, and no output schema, the description does a good job of explaining what it does, how it works (via the filter), and what it returns. However, without an output schema, it could benefit from more detail on the exact structure of the 'chore details' (e.g., field types or examples), though the listed fields (id, content, etc.) provide reasonable coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 already fully documents the lack of inputs. The description adds value by explaining that no parameters are needed because it uses a hardcoded filter ('(today | overdue) & ##Chores') and specifies the data source (Todoist), which isn't in the schema. This compensates well for the parameter-less design.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all chores due today or overdue'), identifies the resource ('from Todoist'), and distinguishes itself from siblings by specifying the exact filter used ('(today | overdue) & ##Chores') and the type of data returned ('structured JSON data with chore details'). This goes beyond 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for chores due today or overdue with a specific Todoist filter), but it doesn't explicitly mention when not to use it or name specific alternatives among the many sibling tools. The implicit alternative would be other task-fetching tools like 'get_tasks_due_tomorrow' or 'get_tasks_due_this_week', but this isn't stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes what the tool returns (context labels with specific naming convention) but doesn't disclose behavioral aspects like authentication requirements, rate limits, error conditions, or whether this is a read-only operation. The description is accurate but lacks 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly sized with two sentences that each earn their place. The first sentence states the core functionality, and the second provides essential clarifying information about what context labels are. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 adequate context about what's returned. However, it doesn't specify the return format (e.g., list of label objects with properties) or mention any limitations (e.g., only returns labels with the 'context:' prefix). Given the tool's simplicity, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 baseline is 4. The description correctly indicates no parameters are needed by not mentioning any, which aligns perfectly with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all context labels from Todoist'), and defines what context labels are (labels starting with 'context:' used to organize tasks). It distinguishes from sibling tools by focusing specifically on context labels rather than tasks, projects, or other Todoist entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to retrieve context labels for organizing tasks), but doesn't explicitly mention when not to use it or name alternatives. It implies usage for getting label metadata rather than tasks themselves, which helps differentiate from task-focused siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the time constraint (last 30 days) and exclusions (subtasks, watched items), which are useful behavioral traits. However, it lacks details on permissions, rate limits, or error handling that would be helpful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and efficiently details exclusions and return format in the second. Every sentence adds value without redundancy, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read-only, time-filtered query), no annotations, and no output schema, the description is mostly complete—it explains what it does, exclusions, and return data. However, it could improve by mentioning authentication needs or response structure more explicitly, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description appropriately adds no parameter information, maintaining a baseline score of 4 for tools with no parameters, as it doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all media tasks'), resource ('from Todoist'), and scope ('created in the last 30 days, excluding subtasks and watched items'), distinguishing it from sibling tools like 'get_tasks_due_today' or 'search_tasks' by its time-based filtering and content focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool (for media tasks within the last 30 days, excluding certain items), but does not explicitly mention when not to use it or name alternative tools for different scenarios, such as 'get_tasks_with_label' for label-based queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes what the tool returns ('structured JSON data with task details') and the specific label filtering logic, but doesn't mention potential limitations like rate limits, authentication requirements, or error conditions. It adequately covers the core behavior but lacks 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and filtering criteria, the second describes the return format. Every element earns its place with no redundant information, and key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description provides good completeness: it explains what's retrieved, the filtering logic, and the return format. However, it doesn't specify whether results are paginated or limited, which could be relevant given Todoist's API constraints. The absence of annotations means some operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately explains that no parameters are needed while clarifying the implicit filtering logic (today/overdue tasks with specific labels), adding meaningful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all tickler tasks'), specifies the source ('from Todoist'), defines what constitutes a tickler task ('tasks with labels #Tickler, #Ansonia Tickler, or #Brian tickler'), and distinguishes from siblings by focusing on overdue/today due tasks with specific labels rather than general task retrieval tools like get_tasks_due_today or get_tasks_with_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('tasks that are due today or overdue' with specific tickler labels), but doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools. It implies usage for tickler-specific overdue tasks rather than general task queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('structured JSON data with task details') and specific fields included, which is useful. However, it doesn't mention behavioral aspects like rate limits, authentication needs, pagination, or error handling, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and includes essential details (filter criteria and return data) without any wasted words. Every part earns its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is largely complete—it specifies what it lists, the filter, and the return format. However, it lacks details on behavioral traits (e.g., read-only nature, potential limits), which would enhance completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description doesn't add param info, which is fine here, but it could have noted the lack of parameters explicitly. Baseline is 4 for 0 params, as it's complete for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'Becky time sensitive tasks from Todoist', including the exact filter criteria '##Becky time sensitive (per BK) & !subtask'. It distinguishes from siblings like 'list_brian_time_sensitive_tasks' by specifying 'Becky' tasks and from general task listing tools by the time-sensitive filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool—when needing Becky's time-sensitive tasks excluding subtasks. However, it doesn't explicitly state when not to use it or name alternatives (e.g., 'list_brian_time_sensitive_tasks' for Brian's tasks), though the specificity helps infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns structured JSON data with specific task details (e.g., id, content, due date), which is helpful behavioral context. However, it does not mention potential limitations like rate limits, authentication needs, or pagination behavior, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose, filter criteria, and return format without any wasted words. It is front-loaded with the core action and resource, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 no parameters) and lack of annotations or output schema, the description is mostly complete: it specifies the filter, data source (Todoist), and return details. However, it could improve by mentioning authentication or rate limits, but for a simple list tool, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description appropriately does not discuss parameters, and the baseline score is 4 for zero parameters, as it avoids unnecessary information while clearly stating the tool's purpose and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all'), resource ('Brian time sensitive tasks from Todoist'), and scope ('using the ##Brian time sensitive (per BP) & !subtask filter'), distinguishing it from siblings like list_becky_time_sensitive_tasks and get_tasks_with_label. It specifies the exact filter criteria, making the purpose highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving Brian's time-sensitive tasks with a specific filter, but does not explicitly state when to use this tool versus alternatives like list_becky_time_sensitive_tasks or get_tasks_due_this_week. It provides clear context (Todoist, Brian, time-sensitive tasks) but lacks explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns structured JSON data with specific task details, which is helpful behavioral information. However, it doesn't mention potential limitations like rate limits, authentication requirements, or whether this is a read-only operation (though 'List' implies reading).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys purpose, filtering criteria, and return format. Every element serves a clear purpose with zero wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0 parameters, no annotations, and no output schema, the description provides good completeness: it explains what the tool does, what filters it applies, and what data it returns. However, it could be more complete by explicitly stating it's a read-only operation or mentioning any authentication context, given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not introducing confusion or redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all GTD projects from Todoist') with specific filtering criteria (using specific project labels and excluding baby-related projects). It distinguishes itself from sibling tools like 'get_brian_only_projects' or 'get_inbox_projects' by focusing on GTD projects with particular label filters and exclusions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when listing GTD projects with specific label filters (#Projects, #Brian projects, #Ansonia Projects) and excluding baby-related projects. However, it doesn't explicitly state when NOT to use it or name alternatives among the many sibling tools (e.g., 'get_brian_only_projects' for different filtering).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the filter behavior and return format (structured JSON with specific fields), which is valuable. However, it doesn't mention authentication needs, rate limits, error conditions, or whether this is a read-only operation (though 'List' implies safe read). More behavioral context would improve this for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the action and filter, the second details the return format. Every element earns its place—no redundant information, well front-loaded with the core purpose. It's appropriately sized for a no-parameter listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple listing with predefined filter), zero parameters, no annotations, and no output schema, the description provides good completeness. It explains the filter logic and return data structure, which compensates for the lack of output schema. However, for a tool with no annotations, adding brief safety/authentication context would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema already fully documents the lack of parameters. The description appropriately doesn't add parameter information beyond what's in the schema, maintaining focus on the tool's purpose and behavior. For zero-parameter tools, a baseline of 4 is appropriate when the description doesn't incorrectly suggest parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all next actions from Todoist') and resource ('next actions'), with precise filtering criteria ('(##Next actions | ##Brian acknowledged) & !subtask filter'). It distinguishes from siblings by focusing on a specific GTD workflow subset, unlike general task listing tools like 'get_tasks_due_this_week' or 'search_tasks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the specific filter criteria, suggesting this tool is for retrieving GTD-style next actions (excluding subtasks). However, it doesn't explicitly state when to use this versus alternatives like 'get_waiting_tasks' or 'list_brian_time_sensitive_tasks', nor does it provide exclusion guidance for other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns structured JSON data with specific task details, which is useful behavioral information. However, it does not mention potential limitations like rate limits, authentication requirements, pagination, or error handling, leaving gaps 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the tool's purpose, source, filter, and output format. Every element adds value without redundancy, making it front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains what the tool does and what data it returns. However, without annotations or output schema, it could benefit from more behavioral details like error cases or data freshness, slightly limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and output. This aligns with the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all personal inbox tasks'), identifies the resource ('from Todoist'), and specifies the scope ('using the ##Inbox filter'). It distinguishes itself from siblings like 'list_becky_inbox_per_brian_tasks' by focusing on personal inbox tasks without user-specific qualifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'personal inbox tasks' and '##Inbox filter', which suggests this tool is for retrieving tasks from a specific Todoist view. However, it does not explicitly state when to use this tool versus alternatives like 'get_tasks_due_tomorrow' or 'search_tasks', nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the search logic (OR-based matching), provides concrete query examples with syntax variations, and details the return format (structured JSON with specific task fields). This gives the agent good operational context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and logic, the second provides examples and return format. Every element serves a clear purpose with zero wasted words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description does well by explaining the OR logic, providing query syntax examples, and detailing the return data structure. However, it doesn't mention potential limitations like result pagination, rate limits, or authentication requirements that would be helpful for comprehensive agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'search_terms' parameter as an array of strings with examples. The description adds value by showing practical search term formats (wildcards, quoted phrases) in context, but doesn't significantly expand on the parameter's semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for tasks in Todoist using OR logic - any search term can match.' It specifies the verb (search), resource (tasks in Todoist), and the distinctive OR logic approach, differentiating it from sibling tools like 'search_tasks' and 'search_tasks_using_and'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by explaining the OR logic behavior ('any search term can match') and offering search query examples. However, it doesn't explicitly state when NOT to use it or directly name alternatives like 'search_tasks_using_and' for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the read-only nature ('Get all tasks') and the filtering behavior ('excluding various project categories'), which is helpful. However, it doesn't mention potential limitations like rate limits, authentication requirements, or error handling, leaving some behavioral aspects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose, exclusions, and return format. Every part earns its place: the action, source, filtering criteria, and output details are all essential and presented without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is quite complete. It explains what the tool does, what it excludes, and what it returns. However, without an output schema, it could benefit from more detail on the JSON structure (e.g., field types or examples), but the provided information is sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 baseline is 4. The description adds no parameter information beyond the schema, but this is acceptable since there are no parameters to document. The description focuses on the tool's purpose and behavior instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all tasks due tomorrow from Todoist') and resource ('tasks'), with explicit exclusions ('excluding various project categories like Tickler, Chores, and baby-related projects'). It distinguishes from siblings like 'get_tasks_due_this_week' by specifying the exact time frame (tomorrow) and filtering criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Get all tasks due tomorrow') and when not to use it ('excluding various project categories like Tickler, Chores, and baby-related projects'). It implicitly suggests alternatives like 'get_tasks_due_this_week' for different time frames or 'get_tasks_with_label' for label-based filtering, making it clear this is for a specific, filtered subset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('structured JSON data') and details included (id, content, etc.), which is valuable. However, it doesn't mention behavioral aspects like pagination, rate limits, authentication needs, or error handling. For a read-only list tool with zero annotation coverage, this is adequate but leaves 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys purpose, usage, and output details without any wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains what the tool does, when to use it, and what it returns. However, without annotations or output schema, it could benefit from more behavioral context (e.g., pagination, errors). For a straightforward list tool, it's largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. A baseline of 4 is assigned as it compensates adequately for the lack of parameters by focusing on output semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all Brian inbox per Becky tasks'), identifies the resource (Todoist tasks), and distinguishes from siblings by specifying the exact filter used ('##Brian inbox - per Becky filter'). It explicitly differentiates from tools like 'list_becky_inbox_per_brian_tasks' and other task-listing tools by its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: for listing tasks from the '##Brian inbox - per Becky filter' in Todoist. It implicitly distinguishes from alternatives like 'list_becky_inbox_per_brian_tasks' (different filter) and 'get_tasks_due_today' (different scope), though it doesn't name them directly. The specificity of the filter provides clear contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool returns ('structured JSON data with task details including id, content, description, completion status, labels, priority, due date, and comment count'), which is valuable since there's no output schema. However, it doesn't mention potential limitations like pagination, rate limits, authentication requirements, or error conditions that would be important for a search 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise: three sentences that each earn their place. First sentence states purpose, second provides sibling differentiation and usage context, third explains syntax options and return format. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description does an excellent job covering purpose, usage context, search syntax, and return format. The main gap is the lack of behavioral details like pagination or error handling, but given the tool's relative simplicity (single parameter, no nested objects), it's quite complete. The description compensates well for the missing output schema by specifying what data will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 the single 'query' parameter. The description adds meaningful context by explaining the three search syntax options (basic text, wildcard, exact phrase) and tying them to the examples already in the schema. This provides helpful semantic understanding beyond the schema's technical specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search for tasks in Todoist using the search filter') and resource ('tasks'), and explicitly distinguishes this tool from its siblings by naming the three search tools and positioning this as the 'basic search (single term)' variant. This provides excellent differentiation from similar tools like search_tasks_using_and and search_tasks_using_or.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: 'This is one of three search tools: basic search (single term), AND search (all terms must match), and OR search (any term can match).' This clearly defines the specific use case for this tool (single term search) versus the other search variants, giving the agent perfect 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by specifying the search logic behavior, providing concrete query examples, and describing the return format ('structured JSON data with task details including id, content, description...'). It doesn't mention rate limits, authentication needs, or pagination, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise - first sentence states purpose and logic, second provides concrete examples, third describes return format. Every sentence earns its place with zero wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 1 parameter, 100% schema coverage, and no output schema, the description provides excellent context: search logic, query examples, and return data structure. It could mention pagination or result limits, but covers the essential information needed to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 the 'search_terms' parameter. The description adds value by providing query examples ('meeting', '*report*', "buy groceries") that illustrate different search syntaxes, but doesn't add semantic meaning beyond what the schema's examples already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Search for tasks') and resource ('in Todoist'), and explicitly distinguishes it from sibling tools by specifying 'AND logic - all search terms must be present'. This differentiates it from 'search_tasks' and 'search_tasks_using_or' which likely use different logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool by stating 'all search terms must be present', which directly contrasts with the 'search_tasks_using_or' sibling tool. This gives clear context for choosing between AND vs OR search logic alternatives.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/bkotos/todoist-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server