Skip to main content
Glama

modify_email

Manage email labels by archiving, trashing, or marking emails as read/unread. Add or remove labels to organize and streamline email workflows efficiently.

Instructions

Modify email labels (archive, trash, mark read/unread, etc.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
add_labelsNo
idYes
remove_labelsNo

Implementation Reference

  • The core handler function for the 'modify_email' tool, decorated with @mcp.tool for automatic registration and schema inference. It authenticates with Google, calls the Gmail API to modify email labels by adding or removing them as specified.
    @mcp.tool(
        name="modify_email",
        description="Modify email labels (archive, trash, mark read/unread, etc.)",
    )
    async def modify_email(id: str, add_labels: Optional[List[str]] = None, remove_labels: Optional[List[str]] = None) -> str:
        """
        Modify email labels (archive, trash, mark read/unread, etc.)
        
        Args:
            id (str): Email message ID
            add_labels (array, optional): Labels to add (e.g., ['INBOX', 'UNREAD'])
            remove_labels (array, optional): Labels to remove (e.g., ['INBOX', 'SPAM'])
        
        Returns:
            str: Success message
        """
        creds = get_google_credentials()
        if not creds:
            return "Google authentication failed."
    
        if not add_labels and not remove_labels:
            return "add_labels 또는 remove_labels 중 하나는 제공되어야 합니다."
    
        try:
            service = build('gmail', 'v1', credentials=creds)
            body = {}
            if add_labels:
                body['addLabelIds'] = add_labels
            if remove_labels:
                body['removeLabelIds'] = remove_labels
    
            message = service.users().messages().modify(userId='me', id=id, body=body).execute()
            logger.info(f"메시지 ID: {message['id']} 수정 완료.")
            return f"이메일 수정 성공. 메시지 ID {message['id']}의 라벨 업데이트 완료."
    
        except HttpError as error:
            logger.error(f"API 오류 발생: {error}")
            return f"Gmail API 오류: {error.resp.status} - {error.content.decode()}"
        except Exception as e:
            logger.exception("이메일 수정 중 오류:")
            return f"예상치 못한 오류 발생: {str(e)}"
  • server.py:200-206 (registration)
    A resource function that lists available tools including 'modify_email', indicating its registration in the system.
    available_google_tools = [
        "list_emails", "search_emails", "send_email", "modify_email",
        "list_events", "create_event", "update_event", "delete_event",
        "search_google", "read_gdrive_file", "search_gdrive"
    ]
    logger.info(f"Resource 'get_available_google_tools' 호출됨. 반환: {available_google_tools}")
    return available_google_tools
  • Function signature and docstring defining the input schema (parameters: id:str, add_labels:Optional[List[str]], remove_labels:Optional[List[str]] ) and output (str success/error message).
    async def modify_email(id: str, add_labels: Optional[List[str]] = None, remove_labels: Optional[List[str]] = None) -> str:
        """
        Modify email labels (archive, trash, mark read/unread, etc.)
        
        Args:
            id (str): Email message ID
            add_labels (array, optional): Labels to add (e.g., ['INBOX', 'UNREAD'])
            remove_labels (array, optional): Labels to remove (e.g., ['INBOX', 'SPAM'])
        
        Returns:
            str: Success message
        """
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. While 'modify' implies a mutation operation, the description doesn't specify whether changes are reversible, what permissions are required, or how errors are handled (e.g., invalid labels). It mentions actions like 'archive' and 'trash' which suggest destructive changes, but lacks explicit warnings or context about their permanence.

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, efficient sentence that front-loads the core purpose. It uses parentheses to provide examples without verbosity. However, the 'etc.' is slightly vague and could be replaced with more precise terminology to improve clarity without sacrificing conciseness.

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?

Given the complexity of a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It fails to explain parameter semantics, behavioral implications (e.g., side effects), or expected outcomes. For a tool that modifies email states, more context on labels, ID sourcing, and result handling is needed.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only vaguely references 'labels' without explaining what 'add_labels' or 'remove_labels' entail, their format, or valid values (e.g., system vs. user labels). The 'id' parameter is not mentioned at all, leaving its purpose ambiguous. The description adds minimal value beyond the schema's property titles.

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 ('modify') and resource ('email labels'), and provides specific examples of modifications (archive, trash, mark read/unread). It distinguishes from obvious siblings like 'send_email' or 'list_emails' by focusing on label manipulation rather than creation or retrieval. However, it doesn't explicitly differentiate from potential overlapping tools like 'update_event' for email-related events.

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 prerequisites (e.g., needing an email ID), exclusions (e.g., not for creating emails), or comparisons to siblings like 'search_emails' for finding emails to modify. The agent must infer usage from the tool name and parameters alone.

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

Related 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/jikime/py-mcp-google-toolbox'

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