Skip to main content
Glama
YUHAI0

email-send-mcp

by YUHAI0

Email Send MCP

A Model Context Protocol server that provides email functionality. This server enables LLMs to compose and send emails, as well as search for attachments within specified directories.

Features

  • Send emails with multiple recipients

  • Support for email attachments

  • Search for files in directories based on pattern matching

  • Secure email transmission using SMTP

Available Tools

  • send_email - Sends emails based on the provided subject, body, and receiver.

    • receiver (array of strings, required): List of recipient email addresses

    • body (string, required): The main content of the email

    • subject (string, required): The subject line of the email

    • attachments (array of strings or string, optional): Email attachments (filenames)

  • search_attachments - Searches for files in a specified directory that match a given pattern.

    • pattern (string, required): The text pattern to search for in file names

Prompts

  • send_email

    • Send an email with optional attachments

    • Arguments:

      • receiver (required): The list of recipient email addresses

      • body (required): The main content of the email

      • subject (required): The subject line of the email

      • attachments (optional): Email attachments

  • search_attachments

    • Search for files matching a pattern

    • Arguments:

      • pattern (required): The text pattern to search for in file names

Related MCP server: Email MCP Server

Usage

Configure for Cursor/Claude

Add to your cursor/claude settings:

Conda

{
  "mcpServers": {
    "email_send_mcp": {
      "command": "uvx",
      "args": [
        "email-send-mcp"
        "--dir",
        "C:\\Users\\YourUserName\\Desktop"
      ],
      "env": {
        "SENDER": "namexxx@gmail.com",
        "PASSWORD": "tuogk......."
      }
    }
  }
}

Security Notes

  • For Gmail and other services, you may need to use an app-specific password

  • The server supports a limited set of attachment file types for security reasons

Supported File Types

The server supports the following attachment file types:

  • Documents: doc, docx, xls, xlsx, ppt, pptx, pdf

  • Archives: zip, rar, 7z, tar, gz

  • Text files: txt, log, csv, json, xml

  • Images: jpg, jpeg, png, gif, bmp

  • Other: md

Example Usage

Sending an Email

{
  "receiver": ["recipient@example.com"],
  "subject": "Test Email from MCP Server",
  "body": "This is a test email sent via the MCP Email Server.",
  "attachments": ["document.pdf", "image.jpg"]
}

Searching for Attachments

{
  "pattern": "report"
}

Contributing

We encourage contributions to help expand and improve the MCP Email Server. Whether you want to add new tools, enhance existing functionality, or improve documentation, your input is valuable.

For examples of other MCP servers and implementation patterns, see: https://github.com/modelcontextprotocol/servers

Pull requests are welcome! Feel free to contribute new ideas, bug fixes, or enhancements to make the MCP Email Server even more powerful and useful.

License

MCP Email Server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License.

Available Tools

2 tools
search_attachmentsC

Searches for files in a specified directory that match a given pattern. The search can be case-insensitive and returns the full paths of all matching files. This tool is useful for locating specific files or attachments within a directory structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
patternYesThe text pattern to search for in file names. The search is case-insensitive by default.

TDQS

C2.9/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. It mentions case-insensitivity and full-path returns, but omits behavioral traits like read-only nature, permissions, or limitations.

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

Conciseness3/5

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

The description is two sentences and fairly concise, but the first sentence is imprecise ('specified directory' with no such parameter), making it less effective.

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?

No output schema exists, and the description does not explain return format, limitations, or how the directory is specified. For a simple tool, more completeness is expected.

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?

Schema coverage is 100% with a description for pattern. The description adds value by clarifying case-insensitivity and that full paths are returned, going beyond the schema.

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

Purpose3/5

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

The description states it searches in a specified directory, but the schema only has a pattern parameter—no directory. This creates ambiguity about how the directory is determined, reducing clarity.

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 description says it's useful for locating files, but provides no when-not-to-use guidance or alternatives. The only sibling (send_email) is distinct, so no conflict, but explicit guidance is missing.

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

send_emailB

A tool that sends emails based on the provided subject, body and receiver. It ensures secure and accurate email delivery while supporting multiple recipients and custom content. Ideal for automating email workflows. After collecting the information, it needs to be displayed to the user, and then selected to send after the user confirms it.

ParametersJSON Schema
NameRequiredDescriptionDefault
receiverYesThe list of recipient email addresses, supports multiple recipients
bodyYesThe main content of the email
subjectYesThe subject line of the email
attachmentsNoEmail attachments, just need to get the file name of the attachment

TDQS

B3.1/5.0
Behavior3/5

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

The description adds a key behavioral trait: the tool requires user confirmation before sending. However, it does not disclose error handling, rate limits, or idempotency. With no annotations, this is moderate transparency.

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

Conciseness3/5

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

The description has three sentences, but the second sentence ('ensures secure and accurate delivery') is generic and could be removed. The confirmation requirement is useful but mixed with fluff.

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?

Covers basic usage and confirmation requirement but omits return values, attachment limits, and validation details. Adequate for a simple mailing tool but not fully comprehensive.

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%, so parameters are well-defined. The description clarifies attachments expect file names, adding value. However, it does not significantly enhance understanding 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 tool sends emails with subject, body, and receiver. It distinguishes from the sibling 'search_attachments' by focusing on sending rather than searching. However, it lacks an explicit contrast statement.

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 on when to use or avoid this tool. It mentions 'ideal for automating email workflows' but provides no exclusion conditions or comparisons with alternatives.

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

TDQS

B3.2/5.0
Disambiguation5/5

The two tools serve completely different purposes—searching files and sending emails—so there is no ambiguity or overlap between them.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (search_attachments, send_email) using snake_case, making them predictable and clear.

Tool Count2/5

With only 2 tools, the server feels very minimal for an email-sending purpose. The inclusion of a generic file search tool rather than email-specific operations (e.g., list inbox, get message) suggests under-scoping.

Completeness3/5

For a server focused on sending emails, the send_email tool covers the core action, and search_attachments helps locate potential attachments. However, it lacks any tools for managing drafts, retrieving sent emails, or handling recipient lists, leaving notable gaps.

Maintenance

ActivityInactive
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

  • A
    license
    Not graded
    quality
    F
    maintenance
    A Model Context Protocol server that enables LLMs to compose and send emails with attachments, as well as search for files in specified directories that match given patterns.
    80
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables AI models to read, search, and send emails via IMAP and SMTP protocols. It supports various providers like Gmail and Outlook, allowing for tasks such as retrieving unread messages, searching by sender, and managing mailbox folders.
  • A
    license
    Not graded
    quality
    D
    maintenance
    A production-ready MCP server that empowers AI agents to securely send emails via SMTP, supporting plain text, HTML, and attachments.
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides Gmail access for LLMs, enabling email composition, sending, searching, and label management via the Gmail API.
    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/YUHAI0/email-send-mcp'

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