Skip to main content
Glama
flesler

MCP Tasks

by flesler
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

MCP Tasks 📋

Install MCP Server npm version Node.js License: MIT Docker

An efficient task manager. Designed to minimize tool confusion and maximize LLM budget efficiency while providing powerful search, filtering, and organization capabilities across multiple file formats (Markdown, JSON, YAML)

📚 Table of Contents

Related MCP server: Task Manager MCP Server

✨ Features

  • ⚡ Ultra-efficient design: Minimal tool count (5 tools) to reduce AI confusion

  • 🎯 Budget-optimized: Batch operations, smart defaults and auto-operations minimize LLM API calls

  • 🚀 Multi-format support: Markdown (.md), JSON (.json), and YAML (.yml) task files

  • 🔍 Powerful search: Case-insensitive text/status filtering with OR logic, and ID-based lookup

  • 📊 Smart organization: Status-based filtering with customizable workflow states

  • 🎯 Position-based indexing: Easy task ordering with 0-based insertion

  • 📁 Multi-source support: Manage multiple task files simultaneously

  • 🔄 Real-time updates: Changes persist automatically to your chosen format

  • 🤖 Auto WIP management: Automatically manages work-in-progress task limits

  • 🚫 Duplicate prevention: Automatically prevents duplicate tasks

  • 🛡️ Type-safe: Full TypeScript support with Zod validation

  • 🔒 Ultra-safe: AI has no way to rewrite or delete your tasks (unless you enable it), only add and move them

  • 📅 Optional reminders: Enable a dedicated Reminders section the AI constantly sees and can maintain

🚀 Quick Start

Add this to ~/.cursor/mcp.json for Cursor, ~/.config/claude_desktop_config.json for Claude Desktop.

Option 1: NPX (Recommended)

{
  "mcpServers": {
    "mcp-tasks": {
      "command": "npx",
      "args": ["-y", "mcp-tasks"]
    }
  }
}

Option 2: Docker

{
  "mcpServers": {
    "mcp-tasks": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "flesler/mcp-tasks"
      ]
    }
  }
}

🤖 AI Integration Tips

To encourage the AI to use these tools, you can start with a prompt like the following, with any path you want with .md (recommended), .json, .yml:

Use mcp-tasks tools to track our work in path/to/tasks.md

If you are telling it about new or updated tasks, you can append this to the end of your prompt:

use mcp-tasks

Adding tasks while AI works: To safely add tasks without interfering with AI operations, use the CLI from a separate terminal:

npx mcp-tasks add "Your new task text" "To Do" 0

🔧 Installation Examples

Full configuration with custom environment:

{
  "mcpServers": {
    "mcp-tasks": {
      "command": "npx",
      "args": ["-y", "mcp-tasks"],
      "env": {
        "STATUS_WIP": "In Progress",
        "STATUS_TODO": "To Do",
        "STATUS_DONE": "Done",
        "STATUS_REMINDERS": "Reminders",
        "STATUS_NOTES": "Notes",
        "STATUSES": "In Progress,To Do,Done,Backlog,Reminders,Notes",
        "AUTO_WIP": "true",
        "PREFIX_TOOLS": "true",
        "KEEP_DELETED": "true",
        "TRANSPORT": "stdio",
        "PORT": "4680",
        "INSTRUCTIONS": "Use mcp-tasks tools when the user mentions new or updated tasks"
      }
    }
  }
}

HTTP transport for remote access:

First run the server:

TRANSPORT=http PORT=4680 npx mcp-tasks

Then:

{
  "mcpServers": {
    "mcp-tasks": {
      "type": "streamableHttp",
      "url": "http://localhost:4680/mcp"
    }
  }
}

📁 Supported File Formats

Extension

Format

Best For

Auto-Created

.md

Markdown

Human-readable task lists

✅

.json

JSON

Structured data, APIs

✅

.yml

YAML

Configuration files

✅

Format is auto-detected from file extension. All formats support the same features and can be mixed in the same project.

Recommended: Markdown (.md) for human readability and editing

⚠️ Warning: Start with a new file rather than using pre-existing task files to avoid losing non-task content.

🛠️ Available Tools

When PREFIX_TOOLS=true (default), all tools are prefixed with tasks_:

Tool

Description

Parameters

tasks_setup

Initialize a task file (creates if missing, supports .md, .json, .yml)

source_path, workspace?

tasks_search

Search tasks with filtering

source_id, statuses?, terms?, ids?

tasks_add

Add new tasks to a status

source_id, texts[], status, index?

tasks_update

Update tasks by ID

source_id, ids[], status, index?

tasks_summary

Get task counts and work-in-progress

source_id

ID Format: Both source_id (from file path) and task id (from task text) are 4-character alphanumeric strings (e.g., "xK8p", "m3Qw").

Tool Examples

Setup a task file:

tasks_setup({
  workspace: "/path/to/project",
  source_path: "tasks.md"  // relative to workspace or absolute
  // source_path: "tasks.json"
  // source_path: "tasks.yml"
})
// Returns: {"source":{"id":"xK8p","path":"/path/to/project/tasks.md"},"Backlog":0,"To Do":0,"In Progress":0,"Done":0,"inProgress":[]}
// Source ID (4-char alphanumeric) is used for all subsequent operations

Add tasks:

tasks_add({
  source_id: "xK8p", // From setup response
  texts: ["Implement authentication", "Write tests"],
  status: "To Do",
  index: 0  // Add at top (optional)
})
// Returns: {"source":{"id":"xK8p","path":"/absolute/path/to/tasks.md"},"Backlog":0,"To Do":2,"In Progress":0,"Done":0,"inProgress":[],"tasks":[{"id":"m3Qw","text":"Implement authentication","status":"To Do","index":0},{"id":"p9Lx","text":"Write tests","status":"To Do","index":1}]}

Search and filter:

tasks_search({
  source_id: "xK8p",        // From setup response
  terms: ["auth", "deploy"],          // Search terms (text or status, OR logic)
  statuses: ["To Do"],      // Filter by status
  ids: ["m3Qw", "p9Lx"]     // Filter by specific task IDs
})
// Returns: [{"id":"m3Qw","text":"Implement authentication","status":"To Do","index":0}]

Update tasks status:

tasks_update({
  source_id: "xK8p",        // From setup response
  ids: ["m3Qw", "p9Lx"],    // Task IDs from add/search responses
  status: "Done"            // Use "Deleted" to remove
})
// Returns: {"source":{"id":"xK8p","path":"/absolute/path/to/tasks.md"},"Backlog":0,"To Do":0,"In Progress":0,"Done":2,"inProgress":[],"tasks":[{"id":"m3Qw","text":"Implement authentication","status":"Done","index":0},{"id":"p9Lx","text":"Write tests","status":"Done","index":1}]}

Get overview:

tasks_summary({
  source_id: "xK8p"         // From setup response
})
// Returns: {"source":{"id":"xK8p","path":"/absolute/path/to/tasks.md"},"Backlog":0,"To Do":0,"In Progress":1,"Done":2,"inProgress":[{"id":"r7Km","text":"Fix critical bug","status":"In Progress","index":0}]}

🎛️ Environment Variables

Variable

Default

Description

TRANSPORT

stdio

Transport mode: stdio or http

PORT

4680

HTTP server port (when TRANSPORT=http)

PREFIX_TOOLS

true

Prefix tool names with tasks_

STATUS_WIP

In Progress

Work-in-progress status name

STATUS_TODO

To Do

ToDo status name

STATUS_DONE

Done

Completed status name

STATUS_REMINDERS

Reminders

Reminders for the AI (empty string to disable)

STATUS_NOTES

Notes

Notes/non-actionable tasks (empty string to disable)

STATUSES

Backlog

Comma-separated additional statuses

AUTO_WIP

true

One WIP moves rest to To Do, first To Do to WIP when no WIP's

KEEP_DELETED

true

Retain deleted tasks (AI can't lose you tasks!)

INSTRUCTIONS

...

Included in all tool responses, for the AI to follow

SOURCES_PATH

./sources.json

File to store source registry (internal)

DEBUG

false

if true, enable the tasks_debug tool

Advanced Configuration Examples

Optional, the WIP/ToDo/Done statuses can be included to control their order.

Custom workflow statuses:

{
  "env": {
    "STATUSES": "WIP,Pending,Archived,Done,To Review",
    "STATUS_WIP": "WIP",
    "STATUS_TODO": "Pending",
    "AUTO_WIP": "false"
  }
}

📊 File Formats

Markdown (.md) - Human-Readable

# Tasks - File Name

## In Progress
- [ ] Write user registration

## To Do
- [ ] Implement authentication
- [ ] Set up CI/CD pipeline

## Backlog
- [ ] Plan architecture
- [ ] Design database schema

## Done
- [x] Set up project structure
- [x] Initialize repository

## Reminders
- [ ] Don't move to Done until you verified it works
- [ ] After you move to Done, commit all the changes, use the task name as the commit message

## Notes
- [ ] The task tools were really great to use!

JSON (.json) - Structured Data

{
  "groups": {
    "In Progress": [
      "Write user registration"
    ],
    "To Do": [
      "Implement authentication",
      "Set up CI/CD pipeline"
    ],
    "Backlog": [
      "Plan architecture",
      "Design database schema"
    ],
    "Done": [
      "Set up project structure",
      "Initialize repository"
    ],
    "Reminders": [
      "Don't move to Done until you verified it works",
      "After you move to Done, commit all the changes, use the task name as the commit message"
    ],
    "Notes": [
      "The task tools were really great to use!"
    ]
  }
}

YAML (.yml) - Configuration-Friendly

groups:
  "In Progress":
    - Write user registration
  "To Do":
    - Implement authentication
    - Set up CI/CD pipeline
  Backlog:
    - Plan architecture
    - Design database schema
  Done:
    - Set up project structure
    - Initialize repository
  Reminders:
    - Don't move to Done until you verified it works
    - After you move to Done, commit all the changes, use the task name as the commit message

🖥️ Server Usage

# Show help
mcp-tasks --help

# Default: stdio transport
mcp-tasks

# HTTP transport
TRANSPORT=http mcp-tasks
TRANSPORT=http PORT=8080 mcp-tasks

# Custom configuration
STATUS_WIP="Working" AUTO_WIP=false mcp-tasks

💻 CLI Usage

You can also use mcp-tasks (or npx mcp-tasks) as a command-line tool for quick task management:

# Setup a task file
mcp-tasks setup tasks.md $PWD                      # Setup with workspace

# Add tasks
mcp-tasks add "Implement authentication"           # Defaults to "To Do" status
mcp-tasks add "Write tests" "Backlog"              # Add with specific status
mcp-tasks add "Fix critical bug" "In Progress" 0   # Add at top (index 0)

# Search tasks
mcp-tasks search                                    # All tasks
mcp-tasks search "" "auth,login"                   # Search for specific terms
mcp-tasks search "To Do,Done" ""                   # Filter by statuses
mcp-tasks search "In Progress" "bug"               # Filter by status and search terms

# Update task status (comma-separated IDs)
mcp-tasks update m3Qw,p9Lx Done

# Get summary
mcp-tasks summary

# Add a reminder (feature must be enabled with REMINDERS=true)
mcp-tasks add "Don't move to Done until you verified it works" Reminders

CLI Features:

  • Direct access to all MCP tool functionality

  • JSON output for easy parsing and scripting

  • Same reliability and duplicate prevention as MCP tools

  • Perfect for automation scripts and CI/CD pipelines

🧪 Development

# Clone and setup
git clone https://github.com/flesler/mcp-tasks
cd mcp-tasks
npm install

# Development mode (auto-restart)
npm run dev              # STDIO transport
npm run dev:http         # HTTP transport on port 4680

# Build and test
npm run build           # Compile TypeScript
npm run lint            # Check code style
npm run lint:full       # Build + lint

🛠️ Troubleshooting

Requirements

  • Node.js ≥20 - This package requires Node.js version 20 or higher

Common Issues

ERR_MODULE_NOT_FOUND when running npx-tasks

  • Problem: Error like Cannot find module '@modelcontextprotocol/sdk/dist/esm/server/index.js' when running npx mcp-tasks

  • Cause: Corrupt or incomplete npx cache preventing proper dependency resolution

  • Solution: Clear the npx cache and try again:

    npx clear-npx-cache
npx mcp-tasks

  • Note: This issue can occur on both Node.js v20 and v22, and the cache clear resolves it

Where are my tasks stored?

  • Tasks are stored in the file path you specified by the AI in tasks_setup

  • The absolute path is returned in every tool call response under source.path

  • If you forgot the location, check any tool response or ask the AI to show it to you

Lost content in Markdown files:

  • ⚠️ The tools will rewrite the entire file, preserving only tasks under recognized status sections

  • Non-task content (notes, documentation) may be lost when tools modify the file

  • Use a dedicated task file rather than mixing tasks with other content

Why not just have AI edit the task files directly?

  • File parsing complexity: AI must read entire files, parse markdown structure, and understand current state - expensive and error-prone

  • Multi-step operations: Moving a task from "In Progress" to "Done" requires multiple read_file, grep_search, sed calls to locate and modify correct sections

  • Context loss: Large task files forcing AI to work with incomplete chunks due to token restrictions and lose track of overall structure

  • State comprehension: AI struggles to understand true project state when reading fragmented file sections - which tasks are actually in progress?

  • Edit precision: Manual editing risks corrupting markdown formatting, losing tasks, or accidentally modifying the wrong sections

  • Concurrent editing conflicts: When AI directly edits files, humans can't safely make manual changes without creating conflicts or overwrites

  • Token inefficiency: Reading+parsing+editing cycles consume far more tokens than structured tool calls with clear inputs/outputs

  • Safety: AI can accidentally change or delete tasks when directly editing files, but with these tools it cannot rewrite or delete your tasks

🤝 Contributing

We welcome contributions! Please:

  1. Fork the repository

  2. Create a feature branch: git checkout -b feature-name

  3. Make your changes with tests

  4. Run: npm run lint:full

  5. Submit a pull request

📄 License

MIT License - see LICENSE for details.

🔗 Links

Available Tools

5 tools
tasks_addB

Add new tasks with a specific status. It's faster and cheaper if you use this in batch. User can add atomically while AI works using the CLI add tool

ParametersJSON Schema
NameRequiredDescriptionDefault
source_idNoSource ID from task_setup() response - Defaults to most recent in the workspace if not provided - Try to always provide it! - If you don't have it, ask the user for a file path and call task_setup()
textsYesEach text becomes a task
statusYesYou might need to infer it from the context: - "To Do" for tasks coming up next (e.g. "Do X next") - "In Progress" for what you'll do now (e.g. "First do X") - "Reminders" instructions for you (the AI) to be constantly reminded of - "Notes" to collect non-actionable notes
indexNo0-based index to place the tasks. e.g.: - 0 for "Do this next" - Omit to place at the end ("Do this later")

TDQS

B3.3/5.0
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.

tasks_setupA

Initializes an source file from a path

  • 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

  • Creates the file if it does not exist

  • Returns the source ID for further use

  • Use mcp-tasks tools when the user mentions new or updated tasks

ParametersJSON Schema
NameRequiredDescriptionDefault
workspaceNoWorkspace/project directory path (provided by the IDE or use $PWD)
source_pathYes

TDQS

A4.2/5.0
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.

tasks_summaryA
Read-only

Get per-status task counts and the WIP task(s). Redundant right after tasks_add/tasks_update

ParametersJSON Schema
NameRequiredDescriptionDefault
source_idNoSource ID from task_setup() response - Defaults to most recent in the workspace if not provided - Try to always provide it! - If you don't have it, ask the user for a file path and call task_setup()

TDQS

A4.4/5.0
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.

tasks_updateA

Update tasks in bulk by ID to a different status. Returns complete summary no need to call tasks_summary afterwards. Prevents AI accidentally rename or deleting tasks during mass updates, not even possible

ParametersJSON Schema
NameRequiredDescriptionDefault
source_idNoSource ID from task_setup() response - Defaults to most recent in the workspace if not provided - Try to always provide it! - If you don't have it, ask the user for a file path and call task_setup()
idsYesThe IDs of existing tasks
statusYesYou might need to infer it from the context: - "To Do" for tasks coming up next (e.g. "Do X next") - "In Progress" for what you'll do now (e.g. "First do X") - "Reminders" instructions for you (the AI) to be constantly reminded of - "Notes" to collect non-actionable notes - "Deleted" when they want these removed - Updating tasks to In Progress moves others to To Do, finishing a In Progress task moves the first Done to In Progress
indexNo0-based index to place the tasks. e.g.: - 0 for "Do this next" - Omit to place at the end ("Do this later")

TDQS

A4.1/5.0
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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updates
    • First observedtasks_add
    • First observedtasks_search
    • First observedtasks_setup
    • First observedtasks_summary
    • First observedtasks_update
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.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.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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