What can you do with this server?

ClawAIMail provides email infrastructure for AI agents, enabling full programmatic control over email operations: * Manage inboxes — Create inboxes with custom usernames (e.g., mybot@clawaimail.com), list all inboxes, or delete them along with their messages. * Send emails — Send to any recipient with a subject, plain text and/or HTML body, from a specified or default inbox. * Read & search messages — List messages (with unread filters and limits), read specific emails by ID, and search by keyword. * Real-time & event-driven — Receive email events via WebSocket streaming or configure webhooks for HTTP callbacks on incoming mail and delivery status. * Account management — Retrieve your agent's email address (auto-created if none exists), and view plan limits and usage stats. * Flexible integration — Use via REST API, MCP server (Claude/Cursor), Node.js/Python SDKs, or self-host for full control. * Custom domains — Bring your own domain or use @clawaimail.com addresses.

ClawAIMail

by joansongjr

Overview Schema Related Servers Score Discussions

Hybrid

ClawAIMail

Email infrastructure for AI agents.

npm version License: MIT Documentation

ClawAIMail gives AI agents their own email addresses and full programmatic control over sending, receiving, and managing email. Built for developers who need reliable email primitives in agentic workflows.

Features

REST API -- Send, receive, search, and manage emails with a simple JSON API.
MCP Server -- First-class Model Context Protocol server for Claude, Cursor, and other MCP-compatible clients.
WebSocket Streaming -- Real-time email events pushed to your agent as they happen.
Webhooks -- HTTP callbacks on incoming mail, delivery status, and other events.
Custom Domains -- Bring your own domain or use a @clawaimail.com address.
SDKs -- Official Node.js and Python SDKs for rapid integration.

Related MCP server: InboxAPI CLI

Quick Start

Node.js

npm install clawaimail

const { ClawAIMail } = require("clawaimail");

const client = new ClawAIMail({ apiKey: process.env.CLAWAIMAIL_API_KEY });

// Create a mailbox for your agent
const mailbox = await client.mailboxes.create({
  name: "support-agent",
  domain: "clawaimail.com",
});

// Send an email
await client.emails.send({
  from: mailbox.address,
  to: "user@example.com",
  subject: "Hello from my AI agent",
  text: "This email was sent by an autonomous agent.",
});

// List incoming emails
const inbox = await client.emails.list({
  mailbox: mailbox.id,
  unread: true,
});

Python

pip install clawaimail

from clawaimail import ClawAIMail

client = ClawAIMail(api_key="your-api-key")

# Create a mailbox
mailbox = client.mailboxes.create(name="support-agent", domain="clawaimail.com")

# Send an email
client.emails.send(
    from_address=mailbox.address,
    to="user@example.com",
    subject="Hello from my AI agent",
    text="This email was sent by an autonomous agent.",
)

# List incoming emails
inbox = client.emails.list(mailbox=mailbox.id, unread=True)

MCP Server

ClawAIMail ships an MCP server so that Claude, Cursor, and other MCP-compatible clients can use email tools directly.

Claude Desktop

Add the following to your Claude Desktop MCP config (claude_desktop_config.json):

{
  "mcpServers": {
    "clawaimail": {
      "command": "npx",
      "args": ["-y", "clawaimail-mcp"],
      "env": {
        "CLAWAIMAIL_API_KEY": "your-api-key"
      }
    }
  }
}

Cursor

Add to your .cursor/mcp.json:

{
  "mcpServers": {
    "clawaimail": {
      "command": "npx",
      "args": ["-y", "clawaimail-mcp"],
      "env": {
        "CLAWAIMAIL_API_KEY": "your-api-key"
      }
    }
  }
}

Once configured, the agent can call tools like send_email, read_inbox, search_emails, and create_mailbox without any additional code.

Self-Hosting

ClawAIMail can be self-hosted for full control over your email infrastructure.

# Clone the repository
git clone https://github.com/joansongjr/clawaimail.git
cd clawaimail

# Install dependencies
npm install

# Configure environment
cp .env.example .env
# Edit .env with your SMTP credentials, database URL, and API keys

# Run database migrations
npm run db:migrate

# Start the server
npm start

The server will be available at http://localhost:3000 by default. See the self-hosting docs for production deployment guides (Docker, Railway, Fly.io).

API Endpoints

Method	Endpoint	Description
`POST`	`/v1/emails/send`	Send an email
`GET`	`/v1/emails`	List emails for a mailbox
`GET`	`/v1/emails/:id`	Get a single email by ID
`DELETE`	`/v1/emails/:id`	Delete an email
`POST`	`/v1/mailboxes`	Create a new mailbox
`GET`	`/v1/mailboxes`	List all mailboxes
`DELETE`	`/v1/mailboxes/:id`	Delete a mailbox
`POST`	`/v1/webhooks`	Register a webhook
`GET`	`/v1/webhooks`	List registered webhooks
`DELETE`	`/v1/webhooks/:id`	Remove a webhook
`GET`	`/v1/domains`	List verified domains
`POST`	`/v1/domains/verify`	Verify a custom domain
`GET`	`/v1/ws`	WebSocket connection for real-time events

Full API reference: clawaimail.com/docs/api

Pricing

	Free	Starter	Pro	Business
Price	$0/mo	$5/mo	$29/mo	$99/mo
Emails/month	100	5,000	50,000	500,000
Mailboxes	1	10	100	Unlimited
Custom domains	--	1	5	Unlimited
Webhooks	1	5	25	Unlimited
WebSocket	--	Yes	Yes	Yes
Support	Community	Email	Priority	Dedicated

Self-hosted deployments are free and unlimited. See clawaimail.com/pricing for details.

License

MIT -- see LICENSE for details.

Available Tools

10 tools

account_infoA

Get account info, plan limits, and usage

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, and the description only states the action without disclosing behavioral traits such as read-only nature, authentication requirements, or side effects. The description alone is insufficient for full transparency.

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 a single, concise sentence of 7 words with no redundancy. Every word is essential.

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?

For a simple parameterless tool, the description covers the three key aspects (account info, plan limits, usage). It could be improved by mentioning the return format or that it is read-only, but it is sufficient for basic understanding.

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?

The tool has no parameters, and schema coverage is 100% (vacuously). The description adds no parameter-specific information, but given the absence of parameters, baseline of 4 is appropriate.

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 tool's purpose with a specific verb 'Get' and resource 'account info, plan limits, and usage'. It distinctively separates from sibling tools focused on inbox and email operations.

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 provides no guidance on when to use this tool versus alternatives. While the tool is standalone, it lacks context on prerequisites or exclusions, so usage is only implied.

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

create_inboxB

Create a new email inbox (optional — a default inbox is auto-created if needed)

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes	Email username (e.g. "mybot" creates mybot@clawaimail.com)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions creation and auto-creation, but fails to indicate idempotency, error behavior for duplicate usernames, or authentication requirements.

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 a single sentence with no wasted words, efficiently conveying the core functionality and optionality.

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?

The description lacks details about the return value or how the created inbox integrates with sibling tools. Given no output schema, this information would aid completeness, but the basic purpose is covered.

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?

The schema covers the single parameter with 100% description coverage, including an example. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 it creates a new email inbox and notes it is optional due to auto-creation. It distinguishes from sibling tools like delete_inbox and list_inboxes.

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 implies usage when a custom inbox is needed, mentioning a default is auto-created. However, it does not explicitly state when to use this tool versus relying on the default or compare with siblings.

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

delete_inboxA

Delete an inbox and all its messages

ParametersJSON Schema

Name	Required	Description	Default
`inbox_id`	Yes	Inbox ID to delete

TDQS

A3.6/5.0

Behavior3/5

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

The description indicates the destructive nature (deletion) but lacks details on irreversibility or side effects. With no annotations, it provides minimal but adequate transparency.

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?

A single, direct sentence that efficiently conveys the tool's action with no unnecessary words.

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?

For a simple delete tool with one parameter and no output schema, the description is sufficiently complete, though it could mention irreversibility for completeness.

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?

The single parameter is fully described in the schema (100% coverage); the description adds no additional meaning or constraints beyond the schema.

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 verb 'delete' and the resource 'inbox', and specifies the scope 'and all its messages', distinguishing it from other inbox-related tools.

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 not use this tool, no mention of alternatives or prerequisites, leaving the agent without context for decision-making.

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

getting_startedA

Interactive onboarding guide for ClawAIMail. Shows you everything you can do with your AI email, step by step.

ParametersJSON Schema

Name	Required	Description	Default
`level`	No	Guide level: "beginner" (default) for basics, "advanced" for power features

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided; the description doesn't disclose whether the tool is read-only, idempotent, or has side effects. The behavioral burden is on the description, which only states it's interactive without safety details.

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?

Two concise sentences that are front-loaded and convey core purpose without waste.

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?

For a simple onboarding tool with one optional parameter and no output schema, the description explains its function adequately. It lacks mention of output format or side effects, but is mostly complete.

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% for the single parameter 'level', which includes an enum and description. The tool description adds no extra meaning beyond the schema.

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 it is an 'Interactive onboarding guide' for ClawAIMail, using specific verbs ('shows', 'step by step'). It distinguishes from sibling tools (all focused on actual email operations) by being a learning resource.

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?

Implied usage for new users ('onboarding', 'step by step') but no explicit when-to-use or when-not-to-use, nor alternatives among siblings.

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

list_inboxesB

List all email inboxes

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description is minimal. It does not disclose behavioral traits like authentication needs, rate limits, or whether the operation is read-only. 'List all email inboxes' implies a read operation, but no further details are given.

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?

Single sentence with no extraneous words. Perfectly concise and front-loaded with the action.

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 simple tool with no parameters, the description is minimally complete. However, it lacks information about the output format or any edge cases (e.g., empty inbox list). Without an output schema, the description should provide more context on what 'list' returns.

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?

The input schema has zero parameters, so schema coverage is 100%. The description adds the word 'all', implying no filtering, which provides marginal semantic value beyond the schema. Per rules, baseline for 0 params is 4.

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 'list' and the resource 'email inboxes', differentiating from sibling tools like 'list_messages' or 'create_inbox'. However, it lacks additional context that might clarify scope or behavior.

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 this tool versus alternatives such as 'search_emails' or 'list_messages'. The description does not mention prerequisites, limitations, or context of use.

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

list_messagesC

List messages. If inbox_id is omitted, uses the default inbox.

ParametersJSON Schema

Name	Required	Description
`inbox_id`	No	Inbox ID (optional, uses default inbox)
`limit`	No	Max messages to return (default 20)
`unread`	No	Only show unread messages

TDQS

C2.7/5.0

Behavior1/5

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

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, authentication needs, rate limits, or pagination. The agent has no insight beyond the basic operation.

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?

Extremely concise at two sentences with no filler. Each sentence adds value.

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?

Lacking output schema and annotations, the description should explain return values (e.g., list of message objects) or pagination. It is too minimal for a tool with 3 parameters and no other structured context.

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 baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, e.g., the default inbox note is already in 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 verb 'List' and resource 'messages', and adds a useful detail about default inbox. It distinguishes from siblings like list_inboxes, but could explicitly differentiate from search_emails.

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 this tool vs alternatives like search_emails or read_email. The description only implies usage but lacks explicit context or exclusions.

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

my_emailA

Get or create your agent's email address. Pass preferred_name to choose your email prefix (e.g. "jarvis" → jarvis@clawaimail.com). If no name given and no inbox exists, a random one is created.

ParametersJSON Schema

Name	Required	Description	Default
`preferred_name`	No	Your preferred email prefix (e.g. "jarvis" creates jarvis@clawaimail.com). If taken, a similar name will be tried.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that no name leads to random creation and that taken names trigger a fallback. However, it doesn't specify if the operation is idempotent (e.g., does it return existing email if already created?) or any side effects.

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?

Two concise sentences convey all necessary information without extraneous detail. Front-loaded with the core purpose.

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?

For a simple tool with one optional parameter and no output schema, the description is adequate. It covers creation and fallback behavior, though it could mention the format of the returned email address.

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% for the single parameter. Description adds value beyond schema by noting that if the preferred_name is taken, a similar name will be tried, which is not in the schema.

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 tool's purpose: 'Get or create your agent's email address.' It identifies the resource (email address) and actions (get or create), distinguishing it from sibling tools like create_inbox.

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?

Description explains when to pass preferred_name and the default behavior if not provided. It could be more explicit about when to use this vs. alternatives like create_inbox, but provides sufficient guidance for typical use.

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

read_emailA

Read a specific email message. If inbox_id is omitted, uses the default inbox.

ParametersJSON Schema

Name	Required	Description	Default
`inbox_id`	No	Inbox ID (optional, uses default inbox)
`message_id`	Yes	Message ID

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. However, it only states the basic action without mentioning side effects, permissions, or error handling. The absence of such context limits transparency.

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 a single, concise sentence that front-loads the core purpose. No extraneous information is included, making it efficient for an agent 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 simple read operation, the description covers the basic purpose and parameter hints. However, it lacks details on return values, error behavior, or whether the email is marked as read, which would be helpful given no output schema.

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?

The input schema already describes both parameters (inbox_id and message_id) with 100% coverage. The description adds no new semantic meaning beyond restating the default inbox behavior, so it provides minimal additional value.

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 explicitly states 'Read a specific email message', clearly defining the action and resource. It differentiates from sibling tools like list_messages or search_emails by focusing on a single message retrieval.

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 provides a usage hint about omitting inbox_id to use the default inbox, but does not specify when to use this tool vs alternatives like search_emails or list_messages. No exclusions or explicit context are given.

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

search_emailsB

Search emails by keyword. If inbox_id is omitted, uses the default inbox.

ParametersJSON Schema

Name	Required	Description	Default
`inbox_id`	No	Inbox ID (optional, uses default inbox)
`query`	Yes	Search query

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full transparency burden. It only discloses that omitted inbox_id defaults to the default inbox, but fails to mention search scope (subject/body), case sensitivity, error handling, or return format.

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 a single sentence with no extraneous words, front-loading the core purpose.

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 lack of annotations and output schema, the description is too brief. It omits expected return values, pagination, sorting, and potential limitations, leaving agents uninformed about behavior.

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 description adds no new information beyond what the schema already provides. The phrase 'by keyword' gives a slight hint about query semantics, but otherwise is redundant.

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 'Search emails by keyword' with a specific verb and resource. It also notes the default inbox behavior, distinguishing it from siblings like list_messages or read_email.

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 implies usage for keyword searches and explains the default inbox behavior, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference sibling tools.

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

send_emailA

Send an email with optional attachments. If inbox_id is omitted, uses the default inbox. Attachments: pass an array of { filename, content (base64), content_type }. Max 5MB per file, 10MB total.

ParametersJSON Schema

Name	Required	Description
`inbox_id`	No	Inbox ID to send from (optional, uses default inbox)
`to`	Yes	Recipient email address
`subject`	Yes	Email subject
`text`	No	Plain text body
`html`	No	HTML body
`attachments`	No	File attachments (max 5MB each, 10MB total)

TDQS

A4.4/5.0

Behavior4/5

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

Discloses attachment size limits and base64 encoding requirement. With no annotations, this adequately informs agent of constraints.

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?

Two concise sentences that front-load the purpose and include critical usage details. No wasted words.

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 purpose, optional behavior, and attachment constraints. Lacks return value description and error cases, but is sufficient for basic usage.

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%, so baseline 3. Description adds attachment size limits and clarifies that content must be base64, going beyond schema.

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 tool sends an email with optional attachments. It is distinct from sibling tools which handle inbox management or account info.

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?

Provides guidance on optional inbox_id defaulting and attachment format. No explicit alternatives to this tool mentioned, but context makes it clear when to use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesMay 3, 2026

Addedgetting_started

Changedmy_email2 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / preferred_name

Added value: +{
+  "description": "Your preferred email prefix (e.g. \"jarvis\" creates jarvis@clawaimail.com). If taken, a similar name will be tried.",
+  "type": "string"
+}

Changedsend_email1 field changed

addedInput schema / properties / attachments

Added value: +{
+  "description": "File attachments (max 5MB each, 10MB total)",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "content": {
+        "description": "File content as base64 string",
+        "type": "string"
+      },
+      "content_type": {
+        "description": "MIME type (e.g. \"application/pdf\"). Defaults to application/octet-stream",
+        "type": "string"
+      },
+      "filename": {
+        "description": "File name (e.g. \"report.pdf\")",
+        "type": "string"
+      }
+    },
+    "required": [
+      "filename",
+      "content"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

9 tool updatesv0.1.0Mar 15, 2026
- First observedaccount_info
- First observedcreate_inbox
- First observeddelete_inbox
- First observedlist_inboxes
- First observedlist_messages
- First observedmy_email
- First observedread_email
- First observedsearch_emails
- First observedsend_email

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct operation: account info, inbox CRUD, message listing/reading/searching/sending, and a getting-started guide. No overlapping purposes.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (e.g., create_inbox, list_messages). However, 'getting_started' (gerund) and 'my_email' (possessive) deviate slightly.

Tool Count5/5

10 tools cover the essential email operations (inbox management, message reading/writing/searching, account info) without being excessive or insufficient.

Completeness4/5

The set includes CRUD for inboxes, message operations, search, and sending with attachments. Missing operations like updating an inbox or deleting a message are minor gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
AgentMailOAuth
to.agentmail
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email Communication
2
AgenticEmail A
dev.agenticemail
Hosted email for AI agents: create inboxes, send, receive, and reply over MCP with scoped API keys
Email Communication
2
CryptoAgentMail
io.github.influqa
Hosted email MCP for AI agents with inboxes, send/receive, memory, recovery, and credits.
Email Communication
21

Related MCP Servers

mcp-server-lobstermail
Email App Automation Customer Support
lobster-kit
A
license
A
quality
C
maintenance
MCP server for LobsterMail — gives AI agents email tools. Create inboxes, send and receive email, search messages, and manage webhooks.
Updated 5 months ago (2026-03-24 13:34 UTC)
11
26
MIT
InboxAPI CLIofficial
Email Communication
inboxapi
A
license
Not graded
quality
B
maintenance
Provides an AI agent with its own email address to send, receive, and manage emails via MCP. No email server setup required.
Updated 3 months ago (2026-06-18 06:02 UTC)
33
12
MIT
Email MCP Server
Email Communication
clemsai
F
license
Not graded
quality
C
maintenance
Give AI agents their own email inboxes. Create, send, receive, and manage email entirely via MCP tools.
Updated 2 months ago (2026-06-23 18:35 UTC)
-
email.deadsimple/dead-simpleofficial
Email Communication
deadsimple-email
A
license
A
quality
D
maintenance
Provides AI agents with real email infrastructure, enabling them to create inboxes, send/receive messages, and extract verification codes from incoming mail.
Updated 9 days ago (2026-08-27 23:16 UTC)
14
MIT

Appeared in Searches

A server for accessing an inbox or messaging system

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/joansongjr/clawaimail'

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

ClawAIMail

Features

Quick Start

Node.js

Python

MCP Server

Claude Desktop

Cursor

Self-Hosting

API Endpoints

Pricing

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

InboxAPI CLIofficial

email.deadsimple/dead-simpleofficial

Appeared in Searches

Latest Blog Posts

MCP directory API