Skip to main content
Glama
jgn35

Todolist MCP Server

by jgn35
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Todolist MCP Server

Python License: MIT Code Style: Ruff

A Model Context Protocol (MCP) server for task management. Built with Python 3.12+, FastMCP, SQLAlchemy, and SQLite.

Features

  • Task Management: Create, read, update, delete, and complete tasks

  • Filtering: List tasks by status, priority, or due date

  • Authentication: Secure token-based authentication

  • Persistence: SQLite database for data storage

  • MCP Protocol: Full MCP server implementation with 6 tools

Available MCP Tools

Tool

Description

create_task

Create a new task with title, description, due date, and priority

get_task

Retrieve a task by its ID

list_tasks

List all tasks with optional filters (status, priority, due date)

update_task

Update task attributes (title, description, due date, priority, status)

delete_task

Delete a task by its ID

complete_task

Mark a task as completed

Related MCP server: Mini Task MCP Server

Quick Start

Prerequisites

  • Python 3.12 or higher

  • uv (recommended) or pip

Installation

# Clone the repository
git clone https://github.com/jgn35/Todolist-mcp.git
cd Todolist-mcp

# Install dependencies with uv
uv sync

# Or with pip
pip install -e .

Generate Authentication Token

All MCP tools require a valid authentication token. Generate one first:

# Using uv
uv run todolist-mcp-generate-token

# Or with Python
python -m todolist_mcp.cli generate-token

# Or directly
python -c "from todolist_mcp.infrastructure.auth_adapter.token_manager import TokenManager; print(TokenManager().generate_token())"

Important: Save the generated token. You'll need it for all MCP tool calls.

Run the Server

# Using uv
uv run todolist-mcp

# Or with Python
python -m todolist_mcp

# Or directly
python -c "from todolist_mcp import main; main()"

The server will start and listen on stdin/stdout for MCP requests.

Usage Examples

Using MCP Client

import asyncio
from mcp import Client

async def main():
    client = Client(command="uv run todolist-mcp")
    await client.connect()
    
    token = "YOUR_GENERATED_TOKEN"
    
    # Create a task
    task = await client.call_tool("create_task", {
        "title": "Learn MCP",
        "description": "Understand Model Context Protocol",
        "priority": "high",
        "token": token
    })
    print(f"Created task: {task['id']}")
    
    # List tasks
    result = await client.call_tool("list_tasks", {"token": token})
    print(f"Total tasks: {result['total']}")
    
    await client.disconnect()

asyncio.run(main())

Direct Tool Calls

from todolist_mcp import mcp
import asyncio

async def example():
    token = "YOUR_GENERATED_TOKEN"
    
    # Create task
    task = await mcp.create_task(
        title="Test Task",
        description="A test task",
        priority="high",
        token=token
    )
    print(f"Created: {task}")
    
    # List tasks
    result = await mcp.list_tasks(token=token)
    print(f"Tasks: {result['tasks']}")

asyncio.run(example())

Project Structure

todolist-mcp/
├── src/
│   └── todolist_mcp/
│       ├── __init__.py           # MCP server entry point & tool definitions
│       ├── cli.py                # Command-line interface for token management
│       ├── domain/
│       │   ├── __init__.py
│       │   └── entities.py        # Task, Priority, TaskStatus entities
│       ├── application/
│       │   ├── __init__.py
│       │   ├── use_cases/         # Clean Architecture use cases
│       │   │   ├── __init__.py
│       │   │   ├── create_task.py
│       │   │   ├── get_task.py
│       │   │   ├── list_tasks.py
│       │   │   ├── update_task.py
│       │   │   ├── delete_task.py
│       │   │   └── complete_task.py
│       │   └── services/
│       │       └── auth_service.py
│       └── infrastructure/
│           ├── __init__.py
│           ├── sqlite_adapter/    # SQLite persistence
│           │   ├── __init__.py
│           │   ├── models.py      # SQLAlchemy models
│           │   └── repository.py  # TaskRepository implementation
│           └── auth_adapter/     # Authentication
│               ├── __init__.py
│               ├── models.py
│               └── token_manager.py
├── tests/
│   ├── __init__.py
│   ├── unit/
│   │   ├── __init__.py
│   │   ├── domain/
│   │   │   └── test_entities.py
│   │   └── application/
│   │       ├── __init__.py
│   │       ├── test_create_task.py
│   │       ├── test_get_task.py
│   │       ├── test_list_tasks.py
│   │       ├── test_update_task.py
│   │       ├── test_delete_task.py
│   │       ├── test_complete_task.py
│   │       └── test_create_task_missing_title.py
│   └── integration/
│       ├── __init__.py
│       ├── test_mcp_tools_integration.py
│       └── mcp_tools/
│           └── __init__.py
├── pyproject.toml                 # Project configuration
├── AGENTS.md                      # Project context for agents
└── LICENSE                        # MIT License

Configuration

Environment Variables

Variable

Description

Default

TODOLIST_MCP_DB_PATH

Path to SQLite database

~/.todolist-mcp/todolist.db

TODOLIST_MCP_TOKEN_PATH

Path to token file

~/.todolist-mcp/token.txt

Token Storage

Tokens are stored in ~/.todolist-mcp/token.txt by default. The directory is created automatically on first run.

Development

Setup Development Environment

# Install development dependencies
uv sync --all-extras

# Or with pip
pip install -e ".[dev]"

Running Tests

# Run all tests
uv run pytest

# Run with verbose output
uv run pytest -v

# Run specific test file
uv run pytest tests/unit/application/test_create_task.py

# Run integration tests
uv run pytest tests/integration/

# Run with coverage
uv run pytest --cov=src/todolist_mcp --cov-report=term-missing

Linting & Type Checking

# Run linter (Ruff)
uv run ruff check .

# Auto-fix linting issues
uv run ruff check . --fix

# Run type checker (Pyright)
uv run pyright

Code Formatting

This project uses Ruff for linting. Configure your editor to use:

  • Line length: 100 characters

  • Python version: 3.12

Architecture

Clean Architecture Layers

┌─────────────────────────────────────────┐
│              MCP Server                  │  ← FastMCP tools
├─────────────────────────────────────────┤
│           Application Layer               │  ← Use cases
├─────────────────────────────────────────┤
│             Domain Layer                  │  ← Entities & interfaces
├─────────────────────────────────────────┤
│          Infrastructure Layer             │  ← SQLite, Auth
└─────────────────────────────────────────┘

Data Flow

MCP Request → Auth Validation → Use Case → Repository → SQLite

Task Entity

from todolist_mcp.domain.entities import Task, Priority, TaskStatus

task = Task(
    title="My Task",
    description="Task description",
    due_date="2026-12-31 23:59:59",
    priority=Priority.HIGH,
    status=TaskStatus.PENDING
)

Priority Levels

  • low - Low priority

  • medium - Medium priority (default)

  • high - High priority

Status Values

  • pending - Task is pending (default)

  • completed - Task is completed

  • cancelled - Task is cancelled

Filtering Tasks

The list_tasks tool supports various filters:

Status Filter

# List only pending tasks
list_tasks(status="pending", token=token)

# List completed tasks
list_tasks(status="completed", token=token)

Priority Filter

# List high priority tasks
list_tasks(priority="high", token=token)

Due Date Filter

# List tasks due today
list_tasks(due_date="today", token=token)

# List tasks due tomorrow
list_tasks(due_date="tomorrow", token=token)

# List overdue tasks
list_tasks(due_date="overdue", token=token)

# List tasks in date range
list_tasks(due_date="2026-08-01..2026-08-31", token=token)

# List tasks due on specific date
list_tasks(due_date="2026-12-31", token=token)

Pagination

# Get first 10 tasks
list_tasks(limit=10, offset=0, token=token)

# Get next 10 tasks
list_tasks(limit=10, offset=10, token=token)

Error Handling

All tools raise ValueError with descriptive messages for:

  • Invalid or missing authentication token

  • Missing required fields (e.g., title for create_task)

  • Invalid field values (e.g., invalid priority)

  • Task not found

  • Attempting to modify a completed task

Contributing

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/your-feature)

  3. Make your changes

  4. Run tests and linting:

    uv run pytest
uv run ruff check .
uv run pyright

  5. Commit your changes (git commit -m 'Add some feature')

  6. Push to the branch (git push origin feature/your-feature)

  7. Open a Pull Request

Pull Request Guidelines

  • Follow existing code style

  • Add tests for new functionality

  • Update documentation as needed

  • Keep commits atomic and well-described

License

This project is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

Available Tools

6 tools
complete_taskComplete TaskA

Mark a task as completed.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesTask UUID

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It states the outcome (marking the task completed) but does not mention idempotency, behavior on already-completed tasks, invalid task IDs, or whether this is a direct status update versus a more comprehensive mutation. For a state-changing tool, this is a notable gap.

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

Conciseness5/5

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

The description is a single five-word sentence that directly states the tool's purpose with zero redundancy. It is front-loaded and every word earns its place.

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

Completeness3/5

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

The tool is simple, has one well-documented parameter, and includes an output schema, so the description need not explain return values. However, the lack of behavioral caveats or guidance on when to use this instead of update_task leaves a small but real completeness gap for an agent making a routing decision.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully documents the only parameter (task_id as a Task UUID), and the description adds no additional meaning beyond what is already in the schema. With 100% schema description coverage, the baseline score of 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb ('mark') and a clear resource ('a task') and conveys the exact state transition to completed. It is immediately distinguishable from sibling tools like create_task, get_task, list_tasks, and delete_task, and even from update_task by signaling a focused finalization action.

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 action itself is obvious, but the description gives no guidance on when to prefer this over update_task, which could also modify task state. It provides no explicit conditions, exclusions, or prerequisites such as the task needing to exist or be in an open state.

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

create_taskCreate TaskB

Create a new task.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesTask title (required)
due_dateNoDue date in YYYY-MM-DD HH:MM:SS format (optional)
priorityNoPriority level (low, medium, high) (optional)
descriptionNoTask description (optional)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a task is created, but does not mention side effects, validation constraints, permission requirements, or what happens on duplicate titles or invalid inputs.

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 with no filler. For a simple creation tool whose parameters are fully documented in the schema, this is appropriately concise.

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

Completeness3/5

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

The description and schema together give enough information to construct a basic create_task call. However, the lack of usage guidance relative to sibling tools and absence of behavioral context makes it only minimally complete for an agent deciding when and how to invoke it.

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 all parameters are already documented in the input schema. The description itself adds no extra meaning to the parameters, matching the baseline for full schema coverage.

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 states a clear verb ('Create') and resource ('a new task'), making the core purpose unambiguous. It is distinct from the sibling operations (get, list, update, delete, complete) by naming the create action, though it does not elaborate on scope or behavior.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as update_task or complete_task. There are no usage contexts, prerequisites, or exclusions mentioned.

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

delete_taskDelete TaskC

Delete a task.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesTask UUID

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must carry the full behavioral burden. 'Delete a task' only signals a destructive action; it does not disclose irreversibility, side effects, permissions, soft-delete behavior, or failure semantics.

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, front-loaded sentence with no filler; every word contributes to the core purpose. It is concise, though it sacrifices valuable behavioral context for brevity.

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 one-parameter destructive tool with an output schema, 'Delete a task' plus the schema is minimally sufficient for a correct call. However, the absence of any behavioral or usage context leaves meaningful gaps for an agent deciding whether deletion is permanent or appropriate.

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 single task_id parameter is already described as 'Task UUID'. The description adds no parameter-level meaning, so the schema fully carries the burden; baseline 3 applies.

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 states a specific verb ('Delete') and a resource ('task'), making the core operation unambiguous and distinct from siblings like create_task or complete_task. However, it adds no scope or nuance beyond the tool name/title, so it does not fully distinguish edge cases like permanent deletion vs. completion.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as complete_task or update_task. No contexts, prerequisites, or exclusions are provided; the agent must infer usage solely from the name.

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

get_taskGet TaskB

Get a task by ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesTask UUID

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the operation without explaining what happens when the task is not found, whether the ID must be a valid UUID, or any error/edge-case behavior. This is a meaningful gap for a retrieval 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 one concise sentence with no filler and appropriate for a simple single-parameter tool. It is not wasteful, though it could add a little context without harming conciseness.

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 low-complexity get-by-ID tool with an output schema, the description is minimally viable. However, with no annotations and no mention of not-found behavior or response shape, it leaves some operational ambiguity. An agent could call it correctly, but the description is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the task_id parameter is already documented as 'Task UUID'. The description adds no new semantic detail beyond aligning 'by ID' with the schema. The baseline of 3 applies because the schema fully carries parameter meaning.

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

Purpose5/5

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

The description uses a specific verb and resource: 'Get a task by ID.' It clearly names the retrieval operation and distinguishes itself from sibling tools like list_tasks, create_task, update_task, delete_task, and complete_task. An agent can tell this is the single-item fetch without opening the schema.

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

Usage Guidelines3/5

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

The intended use is implied by 'by ID' and the sibling set: use when you need one specific task rather than listing all tasks. However, the description does not explicitly state when not to use it or name alternatives. Usage guidance is present only by inference.

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

list_tasksList TasksC

List tasks with optional filters.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of tasks to return (default 50)
offsetNoPagination offset (default 0)
statusNoFilter by status (pending, completed, cancelled)
due_dateNoFilter by due date (YYYY-MM-DD, today, tomorrow, overdue, or range like 2026-08-31..2026-09-02)
priorityNoFilter by priority (low, medium, high)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, but it only says 'List tasks with optional filters.' It does not explicitly state that this is a read-only operation, mention pagination or defaults, or explain how filters interact. The word 'List' is only weak evidence of non-mutating 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 extremely short and front-loaded, with no filler. It could arguably be a bit more informative, but as a one-line summary it is concise.

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

Completeness3/5

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

The rich input schema and presence of an output schema reduce the burden, and the description explains the core operation. However, it omits high-level behavioral context such as whether all tasks are returned by default, ordering, or how multiple filters interact.

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 parameter details are already fully documented. The description merely repeats that filters are optional, adding no new meaning beyond the schema.

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 ('List') and resource ('tasks'), and it mentions filters. It distinguishes itself from sibling CRUD operations by the plural 'list' concept, though it does not explicitly contrast with get_task.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus get_task or the other siblings, and no mention of prerequisites or scenarios. 'List tasks' only implies the obvious collection-retrieval use case.

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

update_taskUpdate TaskC

Update a task.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoNew title (optional)
statusNoNew status (optional)
task_idYesTask UUID
due_dateNoNew due date (optional)
priorityNoNew priority (optional)
descriptionNoNew description (optional)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2/5.0
Behavior1/5

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

With no annotations, the description carries full responsibility for behavioral disclosure, but 'Update a task.' only restates the operation. It does not mention partial-update semantics, null handling, error behavior, or whether the updated task is returned.

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

Conciseness2/5

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

The description is short and front-loaded, but it is under-specified rather than concisely informative. It contains no content beyond the tool name, so the brevity does not contribute value.

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?

For a mutation tool with six parameters and no annotations, a one-sentence description is not sufficiently complete. It omits key invocation context such as whether null clears fields, whether status changes conflict with complete_task, and what happens on invalid task_id.

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 every parameter described in the input schema, so the baseline of 3 applies. The description itself adds no parameter-level meaning, but the schema adequately documents each optional field.

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

Purpose2/5

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

The description 'Update a task.' is a near-verbatim restatement of the tool name/title and provides no additional semantic content. It identifies the resource but does not distinguish this tool from complete_task or create_task beyond the name itself.

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

Usage Guidelines2/5

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

No guidance is given about when to use update_task versus alternatives like create_task, complete_task, or delete_task. The description contains no context about partial field updates or how this differs from completing a task.

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. 6 tool updatesv0.1.0
    • First observedcomplete_task
    • First observedcreate_task
    • First observeddelete_task
    • First observedget_task
    • First observedlist_tasks
    • First observedupdate_task
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool targets a distinct task operation: create, get, list, update, delete, and complete. No overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern using snake_case: create_task, get_task, list_tasks, update_task, delete_task, complete_task.

Tool Count5/5

Six tools is a well-scoped set for a task management server, covering the essential lifecycle without unnecessary bloat.

Completeness5/5

The tool set covers full CRUD operations plus a completion action, providing complete lifecycle coverage for tasks. No obvious gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues

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

  • TaskMateAI

    NewAITees
    A
    license
    Not graded
    quality
    D
    maintenance
    AI-driven task management application that operates via MCP, enabling autonomous creation, organization, and execution of tasks with support for subtasks, priorities, and progress tracking.
    2
    MIT

  • Todo4Agent

    Todo4Agent
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables agents to manage personal task lists through the MCP protocol, supporting task creation, editing, completion, deletion, grouping, reordering, and JSON import/export.
    1
    AGPL 3.0
  • tasqr-mcp by tasqrai

    tasqr-mcpofficial

    tasqrai
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to manage task state through MCP, including creating, updating, and tracking tasks, with support for client-side encryption and secure local credential storage.
    141
    MIT

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/jgn35/Todolist-mcp'

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