MCP Task Management Server

by jimfisher

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 3.1/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as '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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema 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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 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.
Purpose4/5
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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only 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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
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 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 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.
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 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description 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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete 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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases ('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.
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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no 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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses 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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jimfisher/mcp-tasks'

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