Skip to main content
Glama
sidibie1

Task Manager MCP Server

by sidibie1
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

Task Manager MCP Server

A small Model Context Protocol (MCP) server, built in Node.js, that lets an AI assistant like Claude manage a to-do list on your behalf.

It's intentionally minimal — meant as a clear, working example of how MCP tools and resources are wired up, not a production task manager.

What it does

The server exposes:

Tools (actions the model can call):

  • add_task — add a new task with an optional priority

  • list_tasks — list tasks, optionally filtered by open / done

  • complete_task — mark a task as done by ID

  • delete_task — remove a task by ID

Resources (data the model can read):

  • tasks://all — the full task list as JSON

Tasks are persisted to a local tasks.json file, so they survive restarts.

Related MCP server: Todo Markdown MCP Server

Tech stack

  • Node.js (ES modules)

  • @modelcontextprotocol/sdk — official MCP SDK

  • zod — schema validation for tool inputs

  • Transport: stdio (designed to be launched by an MCP host, not run standalone in a browser)

Setup

git clone https://github.com/<your-username>/task-manager-mcp.git
cd task-manager-mcp
npm install

Running it

MCP servers communicate over stdio and are meant to be launched by a host application (like Claude Desktop), not opened directly in a browser.

Connect it to Claude Desktop

Add this to your Claude Desktop config file (%APPDATA%\Claude\claude_desktop_config.json on Windows, or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "task-manager": {
      "command": "node",
      "args": ["/absolute/path/to/task-manager-mcp/index.js"]
    }
  }
}

Restart Claude Desktop, and you'll see the tools show up — you can then just ask Claude things like:

"Add a task to finish the quarterly report, high priority" "What tasks do I still have open?" "Mark task 2 as done"

Project structure

task-manager-mcp/
├── index.js        # The MCP server: tools, resources, and the stdio transport
├── package.json
├── .gitignore
└── README.md

Why this is a useful showcase

This project demonstrates the two core building blocks of MCP:

  • Tools, which let a model take actions with side effects (here: mutating a task list)

  • Resources, which let a model read structured data directly (here: the current task list as JSON)

It's a good starting point to fork and adapt — swap the JSON file for a real database, add more tools, or extend it with prompts.

License

MIT

Available Tools

4 tools
add_taskA

Add a new task to the to-do list

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesShort description of the task
priorityNoTask priority (default: medium)

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosure. It only says 'Add', omitting any behavioral traits like side effects, idempotency, authorization needs, or what happens on conflict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters, the description is minimally adequate but lacks details on return values or expected outcomes, which would help in a complete context.

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 coverage is 100% and the description adds no extra meaning beyond the schema definitions. Baseline 3 is appropriate as the schema already documents both parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Add') and the resource ('task to the to-do list'), which distinguishes it from siblings that list, complete, or delete tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when needing to create a new task, but provides no explicit guidance on when to use this tool versus alternatives or any conditions for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

complete_taskB

Mark a task as complete by its ID

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe numeric ID of the task to complete

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It indicates a state change ('mark as complete') but does not disclose whether changes are reversible, permissions needed, side effects, or return behavior. Minimal transparency.

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?

A single, clear sentence with no wasted words. Efficient but not particularly structured or elegant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple with one parameter, but description lacks context like effects on other tools, return value, or confirmation. No output schema, so more explanation about outcomes would be beneficial.

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 coverage is 100% with one parameter fully described. The description adds no additional meaning beyond the schema's 'The numeric ID of the task to complete'. Baseline score of 3 applies since description does not compensate further.

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 'Mark a task as complete by its ID' uses a specific verb and resource, clearly stating the action and method. It differentiates from sibling tools like add_task, delete_task, and list_tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No prerequisites, conditions, or exclusions mentioned. The description only states what the tool does, not when to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_taskB

Delete a task by its ID

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe numeric ID of the task to delete

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose whether deletion is reversible, what side effects occur, or authentication requirements. This is a significant gap for a destructive operation.

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, concise sentence without unnecessary words. However, it may be too brief to fully inform the agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is minimally adequate but lacks important context about deletion consequences.

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 already describes the single parameter 'id' with 100% coverage. The description adds no additional semantic meaning beyond what the schema provides.

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 verb 'Delete', the resource 'task', and the method 'by its ID'. It distinguishes itself from siblings like add_task, list_tasks, and complete_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when a task needs deletion, but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tasksA

List all tasks, optionally filtered by completion status

ParametersJSON Schema
NameRequiredDescriptionDefault
statusNoFilter tasks by status (default: all)

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must disclose behavioral traits. It does not mention whether the list is paginated, requires authentication, or returns all tasks without performance implications. The term 'all tasks' may be misleading if there is implicit pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key feature. Every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter, the description is minimally adequate. However, it lacks details on default behavior (default status 'all'), output structure, and pagination. Given no output schema, more context would be beneficial.

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 coverage is 100%, with the 'status' parameter fully described via enum and description. The tool description adds minimal value beyond the schema, simply restating the filtering option. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all tasks with an optional filter by completion status. It distinguishes from sibling tools (add_task, complete_task, delete_task) which have different actions.

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 implies usage for listing tasks with optional status filter. No explicit alternatives or when-not to use are mentioned, but sibling tools are all mutating, making this the primary listing tool. Context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct action on tasks: add, list, complete, or delete. No overlap in purpose, and the descriptions are clear.

Naming Consistency5/5

All tools follow the consistent 'verb_task' pattern with snake_case, making the API predictable and easy to navigate.

Tool Count5/5

Four tools cover the essential task management operations without unnecessary bloat, perfectly scoped for a focused utility.

Completeness4/5

Provides CRUD operations for tasks except for update. Missing generic update functionality (e.g., edit description) but the core workflow is complete.

Maintenance

ActivitySlowing
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

  • Todo Markdown MCP Server

    danjdewhurst
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that allows AI assistants to manage todo lists stored in a simple markdown file, supporting creation, reading, updating, and deletion of todo items with persistent IDs.
    5
    21
    6
    MIT

  • Todo MCP

    peterfabakker
    A
    license
    Not graded
    quality
    D
    maintenance
    A persistent todo list server that enables AI assistants to manage tasks across different platforms using the Model Context Protocol. It provides tools for creating, listing, updating, and deleting todos with support for priorities, tags, and due dates.
    MIT

  • Todo MCP Server

    Xczer
    A
    license
    Not graded
    quality
    D
    maintenance
    A small MCP server for managing todos, enabling assistants like Claude to create, update, and query task lists through natural conversation. Stores everything in a local SQLite database.
    18
    1
    ISC

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/sidibie1/mcp-proj'

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