Skip to main content
Glama

TodoWrite

Replace your entire todo list with updated tasks, maintaining task IDs, content, status, priority, and metadata for persistent project management.

Instructions

Update the entire task list (complete replacement).

Parameters: todos: List of todo items, each containing: - id: Unique identifier for the task - content: Task description - status: Current status (pending, in_progress, completed) - priority: Task priority (high, medium, low) - metadata: Optional additional data

Returns success status and count of todos written.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
todosYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Core handler function `todo_write` that performs validation on input parameters and writes the todos list to the persistent store using `store.write_todos`. This contains the primary execution logic for the TodoWrite tool.
    async def todo_write(params: TodoWriteParams) -> TodoWriteResponse:
        """
        Update the entire task list (complete replacement).
    
        Parameters:
            params: Dictionary containing 'todos' list
    
        Returns:
            TodoWriteResponse with success status and todo count
    
        Raises:
            ValidationError: If todos fail validation
        """
        # Validate params structure
        if not isinstance(params, dict):
            raise ValidationError("Parameters must be a dictionary")
    
        if "todos" not in params:
            raise ValidationError("Missing required field: todos")
    
        todos = params["todos"]
    
        try:
            # Write todos (validation happens inside)
            count = await store.write_todos(todos)
    
            return {"success": True, "count": count}
        except ValidationError:
            # Re-raise validation errors
            raise
        except Exception as e:
            # Wrap other errors
            raise ValidationError(f"Failed to write todos: {str(e)}")
  • src/server.py:62-88 (registration)
    MCP tool registration and wrapper handler for `TodoWrite`. Decorated with `@mcp.tool` and delegates to the core `todo_write` function while handling errors.
    @mcp.tool
    async def TodoWrite(todos: list[dict[str, Any]]) -> dict[str, Any]:
        """
        Update the entire task list (complete replacement).
    
        Parameters:
            todos: List of todo items, each containing:
                - id: Unique identifier for the task
                - content: Task description
                - status: Current status (pending, in_progress, completed)
                - priority: Task priority (high, medium, low)
                - metadata: Optional additional data
    
        Returns success status and count of todos written.
        """
        try:
            return await todo_write({"todos": todos})
        except ValidationError as e:
            return {"error": {"code": "VALIDATION_ERROR", "message": str(e)}}
        except Exception as e:
            return {
                "error": {
                    "code": "WRITE_ERROR",
                    "message": f"Failed to write todos: {str(e)}",
                }
            }
  • Type definitions (schemas) for `TodoWriteParams` input and `TodoWriteResponse` output used in the tool implementation.
    class TodoWriteParams(TypedDict):
        todos: list[dict[str, Any]]
    
    
    class TodoWriteResponse(TypedDict):
        success: bool
        count: int
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states this is a 'complete replacement' operation, which implies destructive behavior, but doesn't explicitly warn about data loss or confirm this is a mutation. It mentions return values but doesn't describe error handling, permissions, or rate limits. For a mutation tool with zero annotation coverage, this is insufficient.

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

Conciseness4/5

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

The description is appropriately sized and well-structured with clear sections. The first sentence states the core purpose, followed by detailed parameter documentation and return information. Every sentence adds value, though the return statement could be slightly more 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?

Given this is a mutation tool with no annotations but with output schema (returns success status and count), the description covers parameters well but lacks behavioral context. It doesn't explain what 'complete replacement' means operationally, potential side effects, or error conditions. The output schema reduces need for return value details, but overall completeness is moderate.

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

Parameters5/5

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

The schema has 0% description coverage, so the description must fully compensate. It provides comprehensive parameter semantics: explains 'todos' is a list, documents all nested fields (id, content, status, priority, metadata), specifies enum values for status and priority, and clarifies metadata is optional. This adds substantial meaning beyond the bare 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 tool's purpose: 'Update the entire task list (complete replacement).' It specifies the verb ('update'), resource ('task list'), and scope ('entire', 'complete replacement'). However, it doesn't explicitly differentiate from the sibling TodoRead tool, which prevents a score of 5.

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. It doesn't mention the sibling TodoRead tool, prerequisites, or scenarios where this complete replacement approach is appropriate versus incremental updates. The agent receives no usage context.

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

Install Server

Other Tools

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/joehaddad2000/claude-todo-emulator'

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