Skip to main content
Glama

delete_list

Delete a list from your RTM account. Lists with existing tasks cannot be removed; move or delete tasks first.

Instructions

Delete a list.

Note: Lists with tasks cannot be deleted. Move or delete tasks first.

Args: list_name: Name of the list to delete

Returns: Deletion confirmation with transaction ID

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
list_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The delete_list tool handler: decorated with @mcp.tool(), it finds a list by name (case-insensitive), checks if it's locked, calls rtm.lists.delete API, and returns confirmation with transaction ID for undo support.
    @mcp.tool()
    async def delete_list(
        ctx: Context,
        list_name: str,
    ) -> dict[str, Any]:
        """Delete a list.
    
        Note: Lists with tasks cannot be deleted. Move or delete tasks first.
    
        Args:
            list_name: Name of the list to delete
    
        Returns:
            Deletion confirmation with transaction ID
        """
        from ..client import RTMClient
    
        client: RTMClient = await get_client()
    
        # Find list by name
        lists_result = await client.call("rtm.lists.getList")
        lists = parse_lists_response(lists_result)
    
        list_id = None
        for lst in lists:
            if lst["name"].lower() == list_name.lower():
                if lst["locked"]:
                    return build_response(data={"error": f"Cannot delete locked list: {list_name}"})
                list_id = lst["id"]
                break
    
        if not list_id:
            return build_response(data={"error": f"List not found: {list_name}"})
    
        result = await client.call(
            "rtm.lists.delete",
            require_timeline=True,
            list_id=list_id,
        )
    
        return build_response(
            data={"message": f"Deleted list: {list_name}"},
            transaction_id=get_transaction_id(result),
        )
  • The @mcp.tool() decorator registers delete_list as an MCP tool. The containing function register_list_tools() is called from server.py line 104.
    @mcp.tool()
    async def delete_list(
        ctx: Context,
        list_name: str,
    ) -> dict[str, Any]:
        """Delete a list.
    
        Note: Lists with tasks cannot be deleted. Move or delete tasks first.
    
        Args:
            list_name: Name of the list to delete
    
        Returns:
            Deletion confirmation with transaction ID
        """
        from ..client import RTMClient
    
        client: RTMClient = await get_client()
    
        # Find list by name
        lists_result = await client.call("rtm.lists.getList")
        lists = parse_lists_response(lists_result)
    
        list_id = None
        for lst in lists:
            if lst["name"].lower() == list_name.lower():
                if lst["locked"]:
                    return build_response(data={"error": f"Cannot delete locked list: {list_name}"})
                list_id = lst["id"]
                break
    
        if not list_id:
            return build_response(data={"error": f"List not found: {list_name}"})
    
        result = await client.call(
            "rtm.lists.delete",
            require_timeline=True,
            list_id=list_id,
        )
    
        return build_response(
            data={"message": f"Deleted list: {list_name}"},
            transaction_id=get_transaction_id(result),
        )
  • The register_list_tools function that wraps all list tool registrations including delete_list.
    def register_list_tools(mcp: Any, get_client: Any) -> None:
        """Register all list-related tools."""
  • Registration call: register_list_tools(mcp, get_client) at server startup which includes delete_list.
    # Register all tools
    register_task_tools(mcp, get_client)
    register_list_tools(mcp, get_client)
    register_note_tools(mcp, get_client)
    register_utility_tools(mcp, get_client)
  • parse_lists_response helper used by delete_list to find the list by name.
    def parse_lists_response(result: dict[str, Any]) -> list[dict[str, Any]]:
        """Parse RTM lists response."""
        lists = result.get("lists", {}).get("list", [])
        if isinstance(lists, dict):
            lists = [lists]
    
        return [
            {
                "id": lst.get("id"),
                "name": lst.get("name"),
                "deleted": lst.get("deleted") == "1",
                "locked": lst.get("locked") == "1",
                "archived": lst.get("archived") == "1",
                "position": int(lst.get("position", -1)),
                "smart": lst.get("smart") == "1",
                "filter": lst.get("filter"),
                "sort_order": lst.get("sort_order"),
            }
            for lst in lists
        ]
    
    
    def get_transaction_id(result: dict[str, Any]) -> str | None:
        """Extract transaction ID from response for undo support."""
        transaction = result.get("transaction", {})
        return transaction.get("id")
Behavior3/5

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

No annotations provided. Description notes the task constraint and return type but does not explicitly state irreversibility or potential side effects. Adequate but could be more thorough.

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?

Very concise: two-sentence note followed by structured Args/Returns. No unnecessary words; front-loaded with core action and constraint.

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?

Covers essential context: action, single parameter, return structure, and prerequisite (empty list). Could mention ownership or scope, but sufficient given simplicity.

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

Parameters4/5

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

Input schema has no property descriptions (0% coverage). The description's Args section adds meaning by explicitly stating the parameter's purpose ('Name of the list to delete'), compensating for the schema gap.

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?

Description clearly states the action 'Delete a list' with a specific resource. The note and args further clarify the scope.

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?

Explicitly states when not to use (lists with tasks) and provides alternative actions ('Move or delete tasks first'). Distinguishes from siblings like archive_list.

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/ljadach/rtm-mcp'

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