Skip to main content
Glama

gmail_mark_as_read_by_ids

Mark specific Gmail emails as read using their message IDs. Requires confirmation to execute the action on selected messages.

Instructions

Mark specific emails as read using their message IDs. Requires confirmation to execute.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
message_idsYesComma-separated list of Gmail message IDs to mark as read.
confirmYesMust be true to actually mark as read. Set false to preview.

Implementation Reference

  • Main MCP tool handler that validates input, handles confirmation/preview mode, parses comma-separated message IDs, and invokes GmailClient.mark_as_read.
    elif name == "gmail_mark_as_read_by_ids":
        message_ids_str = arguments.get("message_ids", "")
        confirm = arguments.get("confirm", False)
        
        if not message_ids_str:
            return [TextContent(type="text", text="Error: message_ids is required.")]
        
        # Parse comma-separated IDs
        message_ids = [mid.strip() for mid in message_ids_str.split(",") if mid.strip()]
        
        if not message_ids:
            return [TextContent(type="text", text="Error: No valid message IDs provided.")]
        
        if not confirm:
            return [TextContent(
                type="text",
                text=f"Preview: {len(message_ids)} email(s) would be marked as read. Set confirm=true to proceed."
            )]
        
        result = await client.mark_as_read(message_ids)
        return [TextContent(
            type="text",
            text=f"Success: Marked {result['success']} email(s) as read."
            + (f" Errors: {result['errors']}" if result['errors'] else "")
        )]
  • Tool schema definition including input JSON schema with required parameters: message_ids (comma-separated string) and confirm (boolean).
        name="gmail_mark_as_read_by_ids",
        description="Mark specific emails as read using their message IDs. Requires confirmation to execute.",
        inputSchema={
            "type": "object",
            "properties": {
                "message_ids": {
                    "type": "string",
                    "description": "Comma-separated list of Gmail message IDs to mark as read."
                },
                "confirm": {
                    "type": "boolean",
                    "description": "Must be true to actually mark as read. Set false to preview."
                }
            },
            "required": ["message_ids", "confirm"]
        },
    ),
  • Core GmailClient method implementing the mark as read functionality using Gmail API batchModify to remove the 'UNREAD' label from messages, with batching for large lists and error handling.
    async def mark_as_read(self, message_ids: list[str]) -> dict:
        """Mark one or more emails as read by removing the UNREAD label.
        
        Args:
            message_ids: List of Gmail message IDs to mark as read
            
        Returns:
            Dict with success count and any errors
        """
        if not message_ids:
            return {"success": 0, "errors": [], "message": "No message IDs provided"}
        
        results = {"success": 0, "errors": []}
        
        try:
            # Use batchModify for efficiency (up to 1000 at a time)
            if len(message_ids) <= 1000:
                self.service.users().messages().batchModify(
                    userId="me",
                    body={
                        "ids": message_ids,
                        "removeLabelIds": ["UNREAD"]
                    }
                ).execute()
                results["success"] = len(message_ids)
            else:
                # Process in batches of 1000
                for i in range(0, len(message_ids), 1000):
                    batch = message_ids[i:i+1000]
                    self.service.users().messages().batchModify(
                        userId="me",
                        body={
                            "ids": batch,
                            "removeLabelIds": ["UNREAD"]
                        }
                    ).execute()
                    results["success"] += len(batch)
                    
        except HttpError as e:
            logger.error(f"Failed to mark emails as read: {e}")
            results["errors"].append(str(e))
            
        return results
  • MCP server decorator registering the general call_tool handler which dispatches to specific tool handlers like gmail_mark_as_read_by_ids based on name.
    async def call_tool(name: str, arguments: dict[str, Any]) -> list[TextContent]:
        return await handle_call_tool(name, arguments)
  • MCP server decorator registering list_tools which returns GMAIL_TOOLS containing the gmail_mark_as_read_by_ids tool schema.
    @server.list_tools()
    async def list_tools() -> list[Tool]:
        return GMAIL_TOOLS
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the confirmation requirement and preview capability (via confirm=false), which are not obvious from the schema alone. However, it does not cover other behavioral aspects like permissions needed, rate limits, or what happens on success/failure, leaving gaps for a mutation tool.

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 two sentences, front-loaded with the core purpose and followed by a crucial behavioral note. Every word earns its place with zero waste, making it highly efficient and easy to parse.

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 mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers the purpose and confirmation behavior but lacks details on permissions, error handling, or return values. Given the complexity (modifying email states), more context would be beneficial for safe usage.

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 fully documents both parameters (message_ids and confirm). The description does not add any additional semantic meaning beyond what the schema provides, such as format examples or edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific action ('Mark specific emails as read') and the resource ('using their message IDs'), distinguishing it from sibling tools like 'gmail_mark_as_read_by_query' (which uses queries) and 'gmail_mark_as_unread_by_ids' (which does the opposite). It precisely conveys the verb+resource combination.

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 usage by stating 'Requires confirmation to execute,' which implies a prerequisite (setting confirm=true). However, it does not explicitly mention when to use this tool versus alternatives like 'gmail_mark_as_read_by_query' or 'gmail_mark_as_unread_by_ids,' so it lacks explicit sibling differentiation.

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/murphy360/mcp_gmail'

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