MCP TaskManager

by Rudra-ravi

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 has a clearly distinct purpose with no overlap: request_planning initiates workflows, add_tasks_to_request extends them, get_next_task fetches pending tasks, mark_task_done and approve_task_completion handle task completion steps, delete_task and update_task modify tasks, open_task_details inspects tasks, list_requests provides overviews, and approve_request_completion finalizes requests. The descriptions reinforce these boundaries, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores, such as add_tasks_to_request, approve_request_completion, and get_next_task. There are no deviations in style or convention, making the naming predictable and easy to parse for an agent.
Tool Count5/5
With 10 tools, the set is well-scoped for a task management domain, covering the full lifecycle from planning to completion. Each tool serves a specific role in the workflow, and there are no extraneous or missing tools that would suggest over- or under-engineering.
Completeness5/5
The tool surface provides complete CRUD and lifecycle coverage for task management: request_planning (create), list_requests (read), update_task (update), delete_task (delete), along with workflow-specific tools like get_next_task, mark_task_done, approve_task_completion, and approve_request_completion. There are no obvious gaps, and the descriptions outline a coherent end-to-end process.
Average 3.7/5 across 10 of 10 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 is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists requests but doesn't describe key behaviors: whether it's read-only (implied but not explicit), how results are ordered, if there's pagination, what happens with large datasets, or error conditions. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: two sentences that directly state the purpose and usage. There's no wasted language or redundancy. However, it could be slightly more structured by explicitly separating purpose from context, preventing a perfect score.
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 complexity (simple list operation), no output schema, and no annotations, the description is minimally adequate. It explains what the tool does but lacks details on return format, behavioral traits, or error handling. For a list tool with no structured support, it meets basic requirements but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. A baseline of 4 is given since the schema fully covers the parameters (none exist), and the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all requests with their basic information and summary of tasks.' It specifies the verb ('List'), resource ('requests'), and scope ('all'), and mentions what information is included ('basic information and summary of tasks'). However, it doesn't explicitly differentiate from sibling tools like 'get_next_task' or 'request_planning', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: 'This provides a quick overview of all requests in the system.' It implies this tool is for quick overviews but doesn't specify when to use it versus alternatives (e.g., 'get_next_task' for focused task retrieval or 'request_planning' for planning-related queries). No explicit when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that deletion is limited to uncompleted tasks and mentions a 'progress table will be displayed' as output behavior. However, it lacks details on permissions, error handling, or irreversible effects, which are important for a destructive operation like deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded: the first states the action and constraint, and the second describes the output. There's no wasted text, but it could be slightly more structured (e.g., bullet points for clarity).
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 a destructive tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the basic action and constraint but misses parameter details, error cases, and full behavioral context. It's minimally viable but has clear gaps for such a critical operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain what 'requestId' or 'taskId' represent, their formats, or how to obtain them. The description adds no parameter semantics beyond what the bare schema provides, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a specific task from a request'), making the purpose evident. However, it doesn't explicitly distinguish this tool from sibling tools like 'mark_task_done' or 'update_task', which could also modify task states, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'Only uncompleted tasks can be deleted,' which implies when to use this tool (for uncompleted tasks) and hints at an alternative (e.g., completed tasks might require a different approach). However, it doesn't explicitly name alternatives or specify when not to use it relative to siblings like 'mark_task_done'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks critical behavioral details. It mentions a progress table will be displayed, hinting at output behavior, but doesn't cover permissions, side effects (e.g., if tasks are immediately active), error handling, or rate limits. The description adds some context but is insufficient 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 front-loaded with the core purpose in the first sentence, followed by a clarifying second sentence about the progress table. Both sentences earn their place by adding value, with no wasted 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 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers the basic action and hints at output behavior but lacks details on parameters, error cases, or integration with sibling tools, leaving gaps for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies 'requestId' identifies an existing request and 'tasks' are new tasks to add, but doesn't explain format, constraints, or examples (e.g., what a task object entails beyond title/description). Baseline is 3 as it adds minimal meaning beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('add new tasks') and resource ('to an existing request'), specifying it extends a request with additional tasks. It distinguishes from siblings like 'update_task' or 'delete_task' by focusing on adding rather than modifying or removing, though it doesn't explicitly compare to all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extending an existing request with tasks, but doesn't specify when to use this versus alternatives like 'request_planning' (which might create new requests) or 'update_task' (for modifying existing tasks). No explicit when-not or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is for 'inspecting' (implying read-only) but doesn't clarify permissions, rate limits, or what 'details' include. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. It front-loads the core purpose and adds a brief usage note, making it efficiently structured and easy to parse.
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 no annotations, no output schema, and low schema coverage, the description is incomplete. It covers the basic purpose but lacks details on return values, error conditions, or behavioral traits. For a simple read tool, it's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description adds meaning by specifying that 'taskId' identifies the task to get details for. However, it doesn't explain the format or constraints of 'taskId' beyond what the schema's type indicates. With one parameter, the baseline is 4, but the minimal added value reduces it to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('specific task by taskId'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_next_task' or 'list_requests', which might also retrieve task information in different contexts.
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 inspecting task information at any point') but doesn't specify when to use this versus alternatives like 'get_next_task' or 'list_requests'. It provides some context but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that a 'progress table will be displayed,' which adds some behavioral context about the output. However, it lacks details on permissions, error handling, or mutation effects, which are important for an update 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 appropriately sized with two sentences that are front-loaded: the first states the purpose and constraint, and the second adds output behavior. There's no wasted text, though it could be slightly more structured.
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 no annotations, no output schema, and 0% schema coverage, the description is moderately complete. It covers the purpose, a key constraint, and output behavior, but lacks details on parameters, error cases, or integration with sibling tools, leaving 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 0%, so the description must compensate. It implies that 'title' and 'description' are updatable fields, which adds meaning beyond the schema. However, it doesn't explain 'requestId' or 'taskId' parameters, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and resource 'existing task's title and/or description', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'mark_task_done' or 'delete_task' beyond the update action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with 'Only uncompleted tasks can be updated,' which helps guide when to use this tool. It doesn't explicitly mention alternatives like 'delete_task' or 'mark_task_done' for completed tasks, but the constraint is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key behaviors: it 'finalizes' the request (implying a write/mutation), displays a 'progress table' before approval, and allows continuation via 'request_planning' if not approved. However, it lacks details on permissions, side effects, or error handling, which are important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated in the first sentence. Each sentence adds value: the first explains the action, the second describes a behavioral step (displaying a table), and the third provides an alternative flow. There is minimal waste, though it could be slightly more structured.
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 complexity (a mutation to finalize a request with dependencies on tasks), no annotations, no output schema, and low schema coverage, the description is moderately complete. It covers the purpose, usage context, and some behavioral aspects but lacks details on parameters, return values, and full behavioral transparency, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (requestId) with 0% description coverage, so the description must compensate. It does not explicitly mention the 'requestId' parameter or explain its semantics, such as what format it expects or where to obtain it. The description implies context about tasks and approval but adds no specific parameter information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'finalizes the entire request' and 'confirm that the request is fully completed.' It specifies the action (finalize/confirm) and resource (request), but does not explicitly distinguish it from sibling tools like 'approve_task_completion' or 'mark_task_done,' which handle individual tasks rather than the entire request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'After all tasks are done and approved' and 'to confirm that the request is fully completed.' It also mentions an alternative action if not approved: 'add new tasks using 'request_planning' and continue the process.' However, it does not explicitly state when NOT to use it or compare it directly to all sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: it's an approval step in a workflow, triggers a progress table display, and has conditional outcomes (approval leads to 'get_next_task', disapproval may lead to changes or re-planning). However, it doesn't cover permissions, rate limits, or detailed response 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 appropriately sized and front-loaded with the core purpose and sequence. Every sentence adds value: the first explains the tool's role, the second mentions the progress table, and the third covers disapproval handling. Minor verbosity in the last sentence slightly reduces efficiency.
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 no annotations, 0% schema coverage, and no output schema, the description does well on workflow context but has gaps. It explains when and why to use the tool and ties into sibling tools, but lacks parameter details, return values, and full behavioral transparency (e.g., error cases).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 2 parameters (requestId, taskId), and the description adds no meaning about what these parameters represent, their format, or how to obtain them. It fails to compensate for the schema's lack of documentation, leaving parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'the user must call this tool to approve that the task is genuinely completed' after using 'mark_task_done'. It distinguishes from siblings by specifying this approval step is required before 'get_next_task' can be used, making the verb+resource+sequence explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use after 'mark_task_done', before 'get_next_task', and not to use if the user does not approve. Alternatives are named ('request_planning' for re-planning), and exclusions are clear (do not call 'get_next_task' without approval).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it initiates a workflow, requires user approval after each task and at the end, and interacts with other tools in a specific sequence. It also implies this is a write operation (registering and planning), though it doesn't detail error handling or permissions. The description adds substantial context beyond what's in the schema, making it highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the tool's purpose and required parameters, but it includes extensive workflow instructions that may be overly detailed for a tool description. While these guidelines are helpful, they could be more concise. The text is structured with numbered steps, but some sentences are verbose, such as the repeated emphasis on user approval, which slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (initiating a multi-step workflow with user interactions) and the lack of annotations and output schema, the description is highly complete. It covers the tool's role in the workflow, parameter requirements, behavioral constraints (e.g., approval cycles), and interactions with sibling tools. This provides sufficient context for an AI agent to use the tool correctly despite the missing structured data.
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 description coverage is 0%, so the description must compensate. It specifies that 'originalRequest' and 'tasks' are required, and 'splitDetails' is optional, adding meaning beyond the schema's basic types. It explains that 'tasks' is an array of objects with 'title' and 'description', clarifying the structure. However, it doesn't detail the format or constraints of 'originalRequest' or 'splitDetails', leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Register a new user request and plan its associated tasks.' It specifies the verb ('register' and 'plan') and resource ('user request' and 'tasks'), making the action explicit. However, it doesn't explicitly differentiate from sibling tools like 'add_tasks_to_request' or 'list_requests', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, detailed guidance on when to use this tool versus alternatives. It outlines a complete workflow starting with 'request_planning', followed by 'get_next_task', 'approve_task_completion', and 'approve_request_completion', and explicitly states not to proceed automatically without user approval. It also mentions that if the user wants more tasks after disapproval, 'request_planning' can be used again, distinguishing it from other tools in the cycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it returns a progress table with each response, indicates when no tasks are left, and specifies workflow constraints (e.g., not proceeding without user approval). However, it lacks details on error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but becomes verbose with detailed workflow rules. While all information is relevant, it could be more streamlined. Sentences like 'In other words:' and the bulleted list add redundancy, reducing efficiency.
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 complexity of the workflow and lack of annotations or output schema, the description is mostly complete. It covers purpose, usage rules, and behavioral aspects, but does not detail the structure of the returned task or progress table, which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains that 'requestId' is used to identify which request's tasks to retrieve, adding meaning beyond the bare schema. However, it does not specify the format or source of 'requestId', leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Given a 'requestId', return the next pending task (not done yet).' It specifies the verb ('return'), resource ('next pending task'), and distinguishes it from siblings by focusing on sequential task retrieval rather than listing, adding, or modifying tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines on when to use this tool vs. alternatives. It states not to call 'get_next_task' again until 'approve_task_completion' is called after 'mark_task_done', and to use 'approve_request_completion' or 'request_planning' when all tasks are done, clearly differentiating from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it triggers a progress table display after execution and imposes a workflow constraint (waiting for user approval before using 'get_next_task'). However, it lacks details on error handling, permissions, or rate limits, which are common for mutation tools.
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 appropriately sized and front-loaded, with the first sentence stating the purpose clearly. The subsequent sentences add necessary guidelines without redundancy. However, the phrasing could be slightly more streamlined, e.g., by combining related points into fewer sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with workflow implications), no annotations, and no output schema, the description is fairly complete. It covers purpose, usage rules, and behavioral outcomes like the progress table display. It could improve by mentioning error cases or the exact format of the progress table, but it adequately supports agent decision-making.
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 description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'requestId' and 'taskId' are required and 'completedDetails' is optional, and it implies the context of task completion. While it doesn't detail parameter formats or constraints, it provides essential usage context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Mark a given task as done') and resource ('task'), distinguishing it from siblings like 'update_task' or 'delete_task' by focusing on completion status. It explicitly mentions the required parameters ('requestId' and 'taskId'), reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('after you've completed it') and when not to proceed ('DO NOT proceed to 'get_next_task' again until the user has explicitly approved this completed task using 'approve_task_completion''). It names alternatives ('get_next_task', 'approve_task_completion') and sets clear prerequisites and post-conditions.
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-taskmanager MCP server](https://glama.ai/mcp/servers/Rudra-ravi/mcp-taskmanager/badges/card.svg)](https://glama.ai/mcp/servers/Rudra-ravi/mcp-taskmanager)

Score Badge

Copy to your README.md:

[![mcp-taskmanager MCP server](https://glama.ai/mcp/servers/Rudra-ravi/mcp-taskmanager/badges/score.svg)](https://glama.ai/mcp/servers/Rudra-ravi/mcp-taskmanager)

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/Rudra-ravi/mcp-taskmanager'

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