MCP Tasks

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes: add, search, update, and summary are clearly differentiated. However, tasks_setup is ambiguous—it initializes a source file but overlaps conceptually with tasks_add for task creation, which could cause confusion about when to use each. The descriptions help but don't fully resolve this overlap.
Naming Consistency5/5
All tool names follow a consistent 'tasks_' prefix with a verb suffix pattern (add, search, setup, summary, update). This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming style.
Tool Count5/5
With 5 tools, this server is well-scoped for task management. Each tool serves a specific function (adding, searching, updating, summarizing, and setup), and the count is appropriate for covering core operations without being overwhelming or insufficient.
Completeness3/5
The tool set covers basic CRUD-like operations (add, update, search, summary) but has notable gaps. There is no tool for deleting tasks, which limits lifecycle coverage. Additionally, tasks_setup's role is unclear—it initializes files but doesn't integrate cleanly with other task operations, creating potential dead ends in workflows.
Average 3.9/5 across 5 of 5 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=false, confirming this is a write operation with closed-world behavior. The description adds value by noting batch efficiency and atomic CLI usage, but doesn't disclose critical behavioral traits like error handling, rate limits, or mutation effects beyond what annotations imply. No contradiction with annotations exists.
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 relatively concise but could be more front-loaded. The first sentence states the purpose, but the second sentence about batch efficiency and CLI usage, while useful, adds some redundancy. It's not overly verbose but lacks optimal structure for quick scanning.
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 (4 parameters, write operation) and lack of output schema, the description is moderately complete. It covers basic purpose and usage hints but misses details on return values, error conditions, and sibling tool differentiation. Annotations provide some context, but more behavioral disclosure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain 'texts' or 'status' beyond the schema's enum descriptions). Baseline score of 3 applies as the schema carries the full burden.
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: 'Add new tasks with a specific status.' It specifies the verb ('Add') and resource ('tasks'), and mentions batch capability. However, it doesn't explicitly differentiate from sibling tools like tasks_update or tasks_setup, which could handle similar operations.
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: 'It's faster and cheaper if you use this in batch' and mentions the CLI add tool for atomic operations. However, it lacks explicit guidance on when to use this tool versus alternatives like tasks_update or tasks_setup, and doesn't clarify prerequisites or exclusions beyond the batch efficiency note.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, bounded read operation. The description adds context about filtering capabilities (statuses, text, IDs) and hints at default behavior ('Gets all if omitted' for statuses), but doesn't disclose rate limits, pagination, or error handling. With annotations covering safety, the description provides moderate additional value without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Search tasks from specific statuses') and includes key optional features. There's no wasted language, but it could be slightly more structured (e.g., separating core vs. optional aspects). Overall, it's appropriately concise and clear.
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 moderate complexity (5 parameters, no output schema), the description covers the basic purpose and filtering options. However, it lacks details on return format, error cases, or prerequisites (e.g., needing source_id from task_setup, as hinted in the schema). With annotations providing safety context but no output schema, the description is adequate but leaves gaps for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description mentions 'optional text & ID filtering,' which aligns with the 'terms' and 'ids' parameters but doesn't add meaning beyond what the schema provides (e.g., no extra syntax or format details). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance 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 ('Search') and resource ('tasks'), and specifies filtering by statuses with optional text and ID filtering. It distinguishes itself from siblings like tasks_add (create) and tasks_update (modify), but doesn't explicitly contrast with tasks_summary which might also retrieve tasks. The purpose is clear but sibling differentiation could be more explicit.
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 context through 'Search tasks from specific statuses,' suggesting this tool is for filtered retrieval rather than creation or modification. However, it doesn't provide explicit guidance on when to use this versus tasks_summary (which might summarize tasks) or when not to use it (e.g., for unfiltered lists). Usage is implied but not clearly articulated with alternatives or exclusions.
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?
Annotations indicate readOnlyHint=false and openWorldHint=false, implying a mutation tool with closed-world behavior. The description adds valuable context beyond annotations: it specifies that the tool returns a complete summary, prevents accidental rename/deletion during mass updates, and explains side effects (e.g., updating to 'In Progress' moves others to 'To Do'). This enhances transparency about safety and operational 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 front-loaded with the core purpose and efficiently includes key behavioral details in two sentences. However, the second sentence is slightly verbose ('Prevents AI accidentally rename or deleting tasks during mass updates, not even possible'), which could be tightened without losing meaning. Overall, it's well-structured with minimal waste.
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 (bulk mutation with side effects), annotations cover safety hints, and schema provides full parameter documentation, the description adds necessary context like summary returns and safety precautions. However, without an output schema, it could briefly mention the summary format. It's mostly complete but has a minor gap in output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema, such as implying bulk updates via 'ids' and status changes, but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema carries the primary burden.
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 with specific verb ('Update'), resource ('tasks in bulk by ID'), and scope ('to a different status'). It distinguishes from siblings by emphasizing bulk updates and preventing accidental rename/deletion, unlike tasks_add (adds new), tasks_search (finds), tasks_setup (prepares), and tasks_summary (summarizes).
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 ('Update tasks in bulk by ID to a different status') and mentions an alternative ('no need to call tasks_summary afterwards'), but it doesn't explicitly state when not to use it or compare with other update-related siblings like tasks_add for new tasks. The guidance is helpful but lacks explicit exclusions.
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?
Annotations indicate readOnlyHint=false and openWorldHint=false, implying a write operation with limited scope. The description adds valuable behavioral context beyond annotations: it specifies that the tool creates the file if it doesn't exist, returns a source ID for further use, and should be called once per conversation. This provides practical guidance on side effects and usage patterns, though it doesn't detail error handling or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points, making it easy to scan. Each sentence adds value: the first states the purpose, followed by specific usage rules and behavioral notes. There is no redundant information, and it's front-loaded with the core action, making it highly efficient and clear.
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 (initialization with file creation) and lack of output schema, the description does a good job covering key aspects: purpose, usage guidelines, behavioral traits, and return value (source ID). It doesn't explain error cases or detailed output format, but with annotations providing safety hints and the description adding practical context, it's mostly complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'workspace' has a description). The description mentions 'source file from a path' and 'file path,' which aligns with the 'source_path' parameter, adding some meaning. However, it doesn't explain the 'workspace' parameter or provide details beyond the schema's minimal coverage. With partial schema documentation, the description compensates slightly but not fully, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Initializes an source file from a path' and 'Creates the file if it does not exist.' It specifies the verb ('initializes'), resource ('source file'), and action ('creates if not exist'). However, it doesn't explicitly differentiate from sibling tools like tasks_add or tasks_update, which might also involve file operations, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Always call once per conversation when asked to use these tools,' 'Ask the user to clarify the file path if not given, before calling this tool,' and 'Use mcp-tasks tools when the user mentions new or updated tasks.' It clearly states when to use this tool (initial setup) and includes prerequisites (clarify path if missing), making it highly actionable.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, bounded operation. The description adds valuable behavioral context about redundancy patterns that annotations don't cover, though it doesn't mention performance characteristics like caching or rate limits that would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two brief sentences) and front-loaded with the core purpose. Every word earns its place, with the second sentence providing crucial usage guidance without unnecessary elaboration.
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 read-only tool with good annotations and full schema coverage, the description provides adequate context about purpose and usage patterns. The main gap is lack of output format details (no output schema exists), but the description does specify what information will be returned (counts and WIP tasks).
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?
With 100% schema description coverage, the schema fully documents the single parameter. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline expectation without adding extra semantic value.
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 with specific verbs ('Get per-status task counts and the WIP task(s)') and distinguishes it from siblings by explicitly mentioning redundancy with tasks_add/tasks_update. It identifies both the quantitative output (counts) and qualitative output (WIP 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 guidance on when NOT to use this tool ('Redundant right after tasks_add/tasks_update'), which helps the agent avoid unnecessary calls. It also implies usage context by contrasting with sibling operations, though it doesn't name specific alternatives for all scenarios.
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/flesler/mcp-tasks/badges/card.svg)](https://glama.ai/mcp/servers/flesler/mcp-tasks)

Score Badge

Copy to your README.md:

[![mcp-tasks MCP server](https://glama.ai/mcp/servers/flesler/mcp-tasks/badges/score.svg)](https://glama.ai/mcp/servers/flesler/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/flesler/mcp-tasks'

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