Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Task Management Server Create a high-priority task to review the Q3 budget by Friday"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An advanced Model Context Protocol (MCP) server for comprehensive task management with groups, custom statuses, task relationships, and AI integration. Now powered by SQLite for enhanced performance and reliability.
Task Management: Create, update, delete, and search tasks with rich metadata
Bulk Operations: Create, update, and change status of multiple tasks simultaneously
Task Groups: Organize tasks into projects, areas, or any custom groupings
Custom Statuses: Define your own workflow statuses with colors and descriptions
Task References: Create relationships between tasks (blocks, relates-to, child-of, etc.)
Status History: Automatic tracking of status changes with timestamps
Markdown Support: Task descriptions support full markdown formatting
AI-Friendly: Designed for AI assistants to automatically manage tasks during conversations
Persistent Storage: SQLite database with automatic migration from JSON format
Related MCP server: google-tasks-mcp
Clone or download this repository
Install dependencies:
npm installBuild the project:
npm run buildAdd to your MCP client configuration (e.g., Claude Desktop):
{
"mcpServers": {
"mcp-task": {
"command": "node",
"args": ["/path/to/mcp-task/build/index.js"]
}
}
}You can also run the server directly:
npm startThe server now uses SQLite as the default database for improved performance, reliability, and data integrity. Tasks are stored in ~/.mcp-tasks.sqlite.
Benefits of SQLite:
Better performance for large datasets
ACID transactions ensure data consistency
Structured queries and indexing
Automatic migration from JSON format
For compatibility, the server can still use JSON storage by setting the environment variable:
export MCP_TASK_USE_SQLITE=falseAutomatic Migration: When upgrading from JSON to SQLite, the server automatically migrates your existing ~/.mcp-tasks.json data to the new SQLite format.
create_task: Create a new task with title, description, status, group, priority, tags, assignee, due date, and time estimates
update_task: Update any task properties. Status changes are automatically tracked with timestamps
get_task: Get detailed task information including history and references
list_tasks: List and filter tasks by status, group, assignee, tags, priority, due dates, or search terms
delete_task: Delete a task and remove all references to it
bulk_create_tasks: Create multiple tasks at once with shared properties (group, status, assignee, tags)
bulk_update_tasks: Update multiple tasks simultaneously with the same changes
bulk_change_status: Change the status of multiple tasks at once with optional notes
create_group: Create task groups for organizing related tasks (projects, areas, etc.)
list_groups: List all groups with metadata
delete_group: Delete a group (tasks remain but become ungrouped)
create_status: Create custom workflow statuses with colors and descriptions
list_statuses: List all available statuses
delete_status: Delete custom statuses (cannot delete default or in-use statuses)
add_task_reference: Create relationships between tasks:
blocks / blocked-by: Dependency relationships
relates-to: General relationship
duplicates: Duplicate tasks
child-of / parent-of: Hierarchical relationships
remove_task_reference: Remove task relationships
get_task_references: View all incoming and outgoing task references
This MCP server is specifically designed for AI assistants to:
Automatically create tasks when users mention work they need to do
Update task status as work progresses during conversations
Break down complex requests into manageable subtasks with references
Track project progress by organizing tasks into groups
Manage dependencies by creating task references
Provide context by searching and filtering existing tasks
Handle bulk operations for efficient project setup and team management
Creating tasks from conversation:
User: "I need to implement user authentication and then build the dashboard"
AI: Creates two tasks:
- "Implement user authentication"
- "Build dashboard" (with "blocked-by" reference to auth task)Status tracking:
User: "I finished the login form"
AI: Updates relevant task status to "Done" and adds completion timestampProject organization:
User: "Let's start working on the mobile app redesign"
AI: Creates a "Mobile App Redesign" group and organizes related tasksBulk project setup:
User: "I need to set up tasks for the Q1 marketing campaign"
AI: Uses bulk_create_tasks to create multiple related tasks at once:
- "Design campaign assets", "Write copy", "Set up analytics", etc.Team workflow management:
User: "Move all the design tasks to review status"
AI: Uses bulk_change_status to transition multiple tasks simultaneouslyBasic Info: ID, title, description, summary
Organization: status, group, priority, tags, assignee
Timing: due date, estimated hours, actual hours
Tracking: created/updated timestamps, completion date
Relationships: references to other tasks
History: Complete status change history
Default statuses include "To Do", "In Progress", and "Done", but you can create custom statuses like "Review", "Testing", "Blocked", etc.
Organize tasks into logical groups like:
Projects ("Website Redesign", "Mobile App")
Areas ("Marketing", "Development", "Operations")
Contexts ("Home", "Office", "Travel")
Model complex relationships:
Dependencies: Task A blocks Task B
Hierarchy: Parent/child task relationships
Related work: Tasks that relate to each other
Duplicates: Mark duplicate tasks
The server provides 17 comprehensive tools designed for AI assistants:
Task Operations: create_task, update_task, get_task, list_tasks, delete_task Bulk Operations: bulk_create_tasks, bulk_update_tasks, bulk_change_status Groups: create_group, list_groups, delete_group Statuses: create_status, list_statuses, delete_status References: add_task_reference, remove_task_reference, get_task_references
bulk_create_tasks: Perfect for project initialization, breaking down large initiatives into subtasks, or importing task lists. Supports shared properties (group, status, assignee, tags) that apply to all tasks while allowing individual task customization.
bulk_update_tasks: Ideal for team management scenarios like reassigning multiple tasks, updating priorities across a project, or applying deadline changes to related tasks.
bulk_change_status: Essential for workflow management such as moving multiple tasks through pipeline stages, marking sprint tasks as complete, or transitioning project phases.
Each tool includes comprehensive error handling, detailed result reporting, and maintains data integrity even during partial failures.
npm run buildnpm run devsrc/
├── types.ts # TypeScript type definitions
├── database.ts # Data persistence and management
└── index.ts # MCP server implementationISC License
Create a reference between two tasks (blocks, blocked-by, relates-to, etc.). Use this to model task dependencies and relationships.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of relationship | |
| taskId | Yes | Source task ID | |
| description | No | Optional description of the relationship | |
| referencedTaskId | Yes | Target task ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It communicates that this is a create (mutation) operation and explains the concept of references. However, it does not mention idempotency, duplicate behavior, or whether creating a reference overwrites existing ones, which would be valuable behavioral context. Still, the core action is clear and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, with the primary action front-loaded. It contains no redundant phrases and every clause adds information. The parentheses list of example types is useful and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema with no nested objects and no output schema, so the description need not explain return values. It covers the operation, the relationship types, and the usage intent. It could be marginally more complete by noting whether the reference is bidirectional or directional, but for a reference-creation tool in the context of sibling tools for removal and retrieval, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does 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 minimal value beyond the schema—it enumerates example types in parentheses, but the schema already provides the full enum. No additional parameter semantics, like the directionality of taskId vs referencedTaskId, are explained in the description. Thus, it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('reference between two tasks'), and explicitly lists example relationship types. It clearly distinguishes itself from sibling tools like create_task (which creates a new task) and remove_task_reference/get_task_references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this to model task dependencies and relationships.' This provides clear context for usage. It doesn't explicitly state when not to use or name alternatives, but the purpose is distinct enough from siblings that the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the status of multiple tasks at once with optional note. Perfect for workflow transitions.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional note for the status change | |
| taskIds | Yes | Array of task IDs to update | |
| statusId | Yes | New status ID for all tasks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('change the status') and mentions an optional note, which is already in the schema. It does not disclose potential side effects (e.g., triggering workflow automations), partial failure behavior, or permission requirements. Minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the primary action. It is concise and every word earns its place, with the optional 'workflow transitions' phrase adding a slight use-case flavor without unnecessary clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema, no annotations), the description provides enough to select and invoke correctly. However, it omits details like whether the operation is atomic, what happens if some taskIds are invalid, or if there are any side effects. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (taskIds, statusId, note) already described in the input schema. The description adds no new parameter semantics beyond restating that note is optional. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: changing the status of multiple tasks at once, with an optional note. It distinguishes itself from sibling tools like bulk_update_tasks by focusing specifically on status changes, and the phrase 'workflow transitions' adds context. This is a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Perfect for workflow transitions' implies a use case but does not explicitly state when to use this tool vs alternatives like bulk_update_tasks or update_task. No exclusions or when-not guidance is provided, so usage is implied 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.
Create multiple tasks at once with shared properties. Ideal for breaking down large projects or importing task lists.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Default tags for all tasks | |
| tasks | Yes | Array of tasks to create | |
| groupId | No | Default group ID for all tasks | |
| assignee | No | Default assignee for all tasks | |
| statusId | No | Default status ID for all tasks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, leaving the description to disclose behavioral traits. It only says 'create multiple tasks at once' and does not explain failure modes, atomicity, permissions, or rate limits, which are critical for a bulk operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste, front-loaded with the primary action. The 'Ideal for' clause adds useful context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested tasks array and several default parameters, but the description is quite sparse. With no output schema or annotations, more detail on batch behavior or return values would be helpful, though the schema covers parameter definitions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description introduces the 'shared properties' concept, which explains the purpose of default fields like groupId, assignee, and statusId. With 100% schema description coverage, the schema already documents each parameter, and the description adds contextual meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates multiple tasks at once, distinguishing it from create_task and bulk update/change status tools. It specifies the resource (tasks) and the action (create) with a scope (multiple at once).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases ('breaking down large projects or importing task lists'), signaling when bulk creation is appropriate. It does not explicitly mention when not to use it or name alternatives, so it lacks the full when/when-not/alternatives criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update multiple tasks simultaneously with the same changes. Useful for batch operations like changing assignees or priorities.
| Name | Required | Description | Default |
|---|---|---|---|
| taskIds | Yes | Array of task IDs to update | |
| updates | Yes | Updates to apply to all specified tasks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core behavior (same changes applied to all taskIds) but does not disclose failure semantics (e.g., partial failures if some IDs are invalid), atomicity, whether unspecified fields are overwritten, or any permission/rate concerns. For a mutating bulk operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no unnecessary words. It is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (nested updates object, many optional fields, potential partial failures) and has no output schema or annotations. The description covers what and when but omits behavior like error handling, return format, and update semantics. It is minimally adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does 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 minimal semantic value beyond the schema: it only clarifies that updates apply to all taskIds. Parameter-level details are already well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates multiple tasks simultaneously with the same changes, using a specific verb and resource (update tasks) and a distinctive qualifier (multiple/simultaneously). It distinguishes well from siblings like update_task (single task) and bulk_change_status (status-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly identifies batch operations as the use case and provides examples (changing assignees or priorities). However, it does not explicitly state when not to use it (e.g., when each task needs different changes) or mention alternatives like update_task, so it lacks a clear exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task group for organizing related tasks (e.g., projects, areas, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Group name | |
| color | No | Hex color code for visual identification | |
| description | No | Group description |
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 only states the creation action and purpose, but does not mention any constraints, side effects, permissions, or uniqueness rules, which is a noticeable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and purpose. It contains no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema) and the clear purpose statement, the description is minimally adequate. However, it would benefit from additional context such as what happens if a group with the same name exists or any side effects, especially since there are no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters adequately. The description does not add extra semantic information about parameters, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('task group'), clearly stating its purpose of organizing related tasks. It distinguishes itself from sibling tools like create_task by specifying 'group' and giving examples of use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating task groups, but it does not explicitly state when to use it over alternatives or provide exclusions. The purpose is clear enough to infer usage, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a custom task status with optional color and description.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Status name | |
| color | No | Hex color code | |
| isDefault | No | Make this the default status for new tasks | |
| description | No | Status description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only restates that the tool creates a status and mentions optional parameters, but it does not disclose permissions, duplicate-name behavior, effects on existing tasks, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the key action front-loaded. There is no fluff or unnecessary detail, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and the description does not explain return values, permissions, or error behavior. Although parameters are fully documented in the schema, significant gaps remain for a mutation tool, so the description is not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no new meaning beyond labeling 'color' and 'description' as optional; it does not mention isDefault, but the schema already explains it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and identifies a distinct resource ('custom task status'), which clearly distinguishes it from sibling tools like create_task and create_group. It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only states the action without explaining use cases or how it relates to list_statuses or delete_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task with optional group, status, and metadata. AI should use this to track user requests and break down complex work into manageable tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for categorization | |
| title | Yes | Task title (required) | |
| dueDate | No | Due date in ISO format | |
| groupId | No | Group ID to organize related tasks | |
| summary | No | Brief summary of the task | |
| assignee | No | Person assigned to the task | |
| priority | No | Task priority | |
| statusId | No | Status ID (defaults to default status) | |
| description | No | Detailed description in markdown format | |
| estimatedHours | No | Estimated hours to complete |
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 only states 'Create a new task' without covering return values, permission requirements, output format, or side effects. This is a significant gap for a mutation tool without any annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action 'Create a new task', followed by concise usage guidance. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all 10 parameters well, and the description adds usage context. However, there is no output schema, and the description does not mention return values, error behavior, or alternatives like bulk creation. It is adequate but not fully complete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does 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 mentions 'optional group, status, and metadata' but adds no extra meaning beyond what the schema already provides for each parameter. It does not compensate for any schema gaps because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the specific verb+resource 'Create a new task' and notes optional group, status, and metadata. This clearly distinguishes it from siblings like update_task and bulk_create_tasks. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly states when to use this tool: 'AI should use this to track user requests and break down complex work into manageable tasks.' This provides clear context, but it does not mention alternatives or when not to use (e.g., bulk_create_tasks for multiple tasks).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a group. Tasks in the group will be ungrouped but not deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals a critical non-obvious outcome: tasks are ungrouped but not deleted. This is valuable transparency, though it could also state that group deletion itself is irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no unnecessary detail. It is front-loaded with the primary action and adds the essential side effect efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter deletion tool with no output schema, the description covers purpose, primary behavior, and the most important side effect. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'id' parameter described as 'Group ID'. The description adds no additional parameter meaning, meeting the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' with a clear resource ('a group'), and the context distinguishes it from sibling tools like delete_task and create_group. It unambiguously states the action and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies the key consequence of deleting a group (tasks ungrouped but not deleted), which implicitly guides usage when tasks should be preserved. It does not explicitly mention alternative tools, but the side-effect note serves as practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a custom status. Cannot delete default status or statuses in use.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Status ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important constraint about default/in-use statuses, which warns about potential failures. However, it does not describe what happens when a constraint is violated (error vs. no-op) or the permanent nature of deletion, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences without redundancy. The main action is front-loaded in the first sentence, and the constraint follows immediately. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the essential behavior and a critical limitation. It does not detail return values or error handling, but for a straightforward delete operation, the coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'id' as 'Status ID', but the tool description adds that it must be a custom status not in use, giving the parameter additional semantic meaning. This goes beyond the schema's basic definition and justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('custom status'), making it unambiguous. It distinguishes from siblings like create_status and list_statuses by specifying the operation and 'custom' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool is applicable and explicitly states when it cannot be used ('Cannot delete default status or statuses in use'). However, it does not mention alternative tools or provide broader usage scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task and remove all references to it from other tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It does mention a key side effect ('remove all references to it from other tasks'), which is valuable. However, it does not state that the operation is irreversible, does not mention permissions, and does not describe the outcome or response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the core action and includes the important side effect efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description is largely sufficient: it states the action and a critical side effect. It could be slightly more complete by noting irreversibility, but the absence of an output schema means no return-value details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'id' with a basic description. The tool description adds no additional meaning about the parameter or its format, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a task') and the resource, and adds a distinguishing detail about removing references from other tasks. This differentiates it from sibling tools like delete_group and delete_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this when you need to delete a task. However, there is no explicit guidance about when not to use it, nor any comparison with alternatives like remove_task_reference or update_task. The side-effect note provides some context but not direct usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific task including its history, references, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. 'Get' clearly conveys a read-only operation, and the phrase 'including its history, references, and metadata' sets expectations about the return payload. It does not mention error cases or auth, but for a simple fetch tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, contains no filler, and every word adds value. It is optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers the purpose and return contents. It explains what detailed information includes, making it complete for a get-by-ID operation. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with only the 'id' parameter documented as 'Task ID'. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate here. The description does not explain the format or constraints of the ID beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed information about a specific task'), and clarifies scope by mentioning 'history, references, and metadata.' This distinguishes it from sibling tools like list_tasks (lists all tasks) and get_task_references (only references).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need detailed information for one specific task, but it does not explicitly state when to use this tool versus alternatives like list_tasks or get_task_references. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all incoming and outgoing references for a task to understand dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds value by specifying that both incoming and outgoing references are returned, which is useful context. However, it does not disclose the response format, error behavior, or prerequisites (e.g., whether the task must exist), leaving gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and purpose. It contains no unnecessary words and is easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides essential purpose and scope but omits details about the structure of the returned references (e.g., whether they are grouped by direction, what fields they contain). This lack of output clarity could hinder an agent's ability to interpret results, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter taskId, which is described simply as 'Task ID'. The description does not add additional semantics or details about taskId beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves references for a task, using a specific verb ('Get') and resource ('references') with a scope ('for a task'). It also conveys the purpose ('to understand dependencies'), which distinguishes it from siblings like get_task (task details) and add/remove_task_reference (mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding task dependencies but does not explicitly mention when to use this tool versus alternatives like get_task or list_tasks. No exclusions or alternative tool references are provided, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all task groups with their metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description relies on the word 'List' to imply a non-destructive read. However, it does not clarify behavior such as ordering, pagination, or whether metadata includes nested fields. It adds minimal transparency beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the verb and resource. It is extremely concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list, but it lacks specificity about what 'metadata' includes and does not mention return structure, particularly with no output schema. There is also no mention of behavior like grouping or sorting, making it incomplete for an agent needing full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is empty, so the description needs to add nothing about parameter semantics. The baseline for 0 params is 4, and the description does not detract from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with resource 'task groups' and states it returns 'metadata', clearly distinguishing from task-centric siblings like list_tasks. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_tasks or create_group. It does not state any context, exclusions, or prerequisites, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available task statuses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 simply states 'List all available task statuses' without explicitly confirming this is read-only, whether it includes inactive or archived statuses, or what the response format looks like. The word 'List' implies read-only, but that is not explicitly stated, and no other behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that conveys the core action without any extraneous words. It is front-loaded and perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple with no parameters, but the description does not mention what the return value looks like, and there is no output schema to fill that gap. It is adequate for basic understanding but lacks detail on the response structure (e.g., an array of status objects), so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema shows zero parameters, so the baseline score of 4 applies. The description does not need to add parameter meaning because there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('all available task statuses'), distinguishing it from sibling tools like list_tasks (tasks) and create_status/delete_status (mutations). It is 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to enumerate statuses but provides no explicit guidance on when to use it instead of alternatives, nor any exclusions. For a list operation, the use case is fairly obvious, so it earns a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks with optional filtering. AI should use this to understand current workload, find related tasks, and provide context-aware assistance.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by tags | |
| search | No | Search in title, description, and summary | |
| dueAfter | No | Due after this date | |
| groupIds | No | Filter by group IDs | |
| assignees | No | Filter by assignees | |
| dueBefore | No | Due before this date | |
| statusIds | No | Filter by status IDs | |
| priorities | No | Filter by priorities |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the tool lists tasks with optional filtering, implying a read operation, but omits details like pagination, sorting, or default scope (e.g., whether it returns all tasks or only those assigned to the current user). This is a notable gap for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with a front-loaded purpose statement followed by a short AI-assistance note. The second sentence is somewhat vague and could be considered filler, but it does add a use-case context without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 optional parameters, no output schema, and no annotations, yet the description does not explain pagination, return shape, or what the default result set looks like. While the schema covers parameters, the description fails to provide essential context for a list operation, making it incomplete for real-world usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters (tags, search, dueAfter, groupIds, etc.). The description only adds 'optional filtering' as a general statement and does not enrich parameter understanding beyond what the schema provides, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List tasks with optional filtering,' which clearly states the verb, resource, and scope. It does not explicitly differentiate from sibling tools like get_task, though 'list' inherently contrasts with single-task retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says the AI should use this to 'understand current workload, find related tasks, and provide context-aware assistance,' giving a general use case. However, it does not name alternatives or specify when not to use it, relying on weak implied context rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a reference between two tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Reference type to remove | |
| taskId | Yes | Source task ID | |
| referencedTaskId | Yes | Target task ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states 'Remove a reference' without explaining any side effects, such as whether the operation is irreversible, if it fails when the reference does not exist, or if any related data is affected. This lack of detail makes it difficult for an agent to anticipate the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence that communicates the core purpose without any filler. It is front-loaded and efficient, earning its place, though it could be slightly more informative without compromising conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is very sparse. There is no output schema or annotations to compensate, and the description does not explain what a 'reference' is, what the 'type' parameter represents, or what happens after removal. Given the lack of any additional context, the description is incomplete for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions (taskId, referencedTaskId, type), so the baseline is 3. The description does not add any extra meaning beyond what the schema already provides, but it does not contradict or omit information either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a reference between two tasks' uses a specific verb ('Remove') and indicates the resource (a reference between tasks), which clearly distinguishes it from sibling tools like 'add_task_reference' and 'get_task_references'. It directly states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'add_task_reference' or 'get_task_references'. There is no mention of prerequisites, conditions, or context that would help an agent decide to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task. Use this to change status, add progress notes, update estimates, etc. Status changes are automatically tracked with timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID (required) | |
| tags | No | Updated tags | |
| title | No | Updated title | |
| dueDate | No | Updated due date | |
| groupId | No | Move to different group | |
| summary | No | Updated summary | |
| assignee | No | Updated assignee | |
| priority | No | Updated priority | |
| statusId | No | New status ID - changes are tracked | |
| actualHours | No | Actual time spent | |
| description | No | Updated description in markdown | |
| estimatedHours | No | Updated time estimate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one useful behavioral trait: status changes are automatically tracked with timestamps. But with no annotations provided, it does not carry enough burden for a mutation tool—it lacks details on partial vs. full update, error handling, or permissions, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the primary action. It avoids redundancy and efficiently conveys the core purpose plus one behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 12 parameters and no output schema, the description provides a solid high-level overview and a key behavioral detail. It could be more complete by explicitly stating partial update semantics, but it is sufficient for an agent to select and invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 12 parameters with 100% coverage, so the baseline is 3. The description adds no new parameter-specific semantics beyond generic mentions of 'change status' and 'update estimates,' which are already evident from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing task' with a specific verb and resource, making it distinct from create_task and delete_task. It also enumerates key update actions (change status, add progress notes, update estimates), reinforcing the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this to change status, add progress notes, update estimates, etc.' provides clear context for when to use this tool. However, it does not explicitly mention alternatives like bulk_update_tasks or bulk_change_status, so it falls short of fully specifying when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_task_referencebulk_change_statusbulk_create_tasksbulk_update_taskscreate_groupcreate_statuscreate_taskdelete_groupdelete_statusdelete_taskget_taskget_task_referenceslist_groupslist_statuseslist_tasksremove_task_referenceupdate_taskEach tool targets a distinct resource and action: tasks, groups, statuses, references, and bulk operations are clearly separated. No two tools overlap in purpose, and the singular vs. bulk distinction is explicit.
All tools use a consistent verb_noun pattern in snake_case, with 'bulk_' prefixed for batch operations. This makes the tool set highly predictable and easy to navigate.
With 17 tools, the server covers tasks, groups, statuses, references, and bulk operations comprehensively. While slightly above the ideal 10-15 range, the count is justified by the broad domain and no tools seem redundant.
The task lifecycle (CRUD), references, and bulk operations are fully covered. Minor gaps include missing update operations for groups and statuses (e.g., rename group, change status metadata), but these can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native task management: list, create, update and archive tasks with rich context for AI agents
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Task management for teams building with AI agents. Agents claim tasks and report progress.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jimfisher/mcp-tasks'
If you have feedback or need assistance with the MCP directory API, please join our Discord server