Which integrations are available for this server?

Enables AI agents to receive and verify emails from Resend, such as confirmation emails, facilitating automated sign-up and email verification workflows. Enables AI agents to receive and verify emails from SendGrid, such as confirmation emails, facilitating automated sign-up and email verification workflows. Enables AI agents to receive and verify emails from Supabase, such as confirmation emails, facilitating automated sign-up and email verification workflows.

How do I use agent-inbox?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-inbox Create an inbox for signing up to testservice.com and wait for the confirmation email" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

agent-inbox

by gsd-build

Overview Schema Related Servers Score Discussions

JavaScript

Remote

agent-inbox

Give any AI agent a disposable email inbox in one tool call.

Install

npx gsd-agent-inbox

The interactive installer auto-detects your AI coding agents (Claude Code, Codex CLI, Cursor, Gemini CLI, Windsurf), configures the MCP server, and installs the optional skill for each.

When launched by an MCP client (non-TTY), it starts the MCP server normally. When you run it from a terminal, you get the installer.

Related MCP server: courier-mcp

What it does

An MCP server that creates real, temporary email addresses on demand. Your agent can sign up for services, receive confirmation emails, extract verification links, and clean up — without you lifting a finger.

No API keys. No accounts. No configuration. Works with any email-sending service — Supabase, Resend, SendGrid, Postmark, AWS SES, whatever.

The problem

AI agents hit a wall when a service requires email verification. They can fill out a sign-up form, but they can't receive the confirmation email. So they stop and ask you to do it.

The fix

Agent: create_inbox({ prefix: "signup", name: "test" })
→ signup-1712345678@somedomain.com (name: test)

Agent: [fills sign-up form with that email]

Agent: verify_email({ address: "test", subject_contains: "confirm" })
→ Email verified successfully!
  Verification URL: https://myapp.supabase.co/auth/v1/verify?token=abc123
  HTTP Status: 200

Agent: delete_inbox({ address: "test" })
→ Done.

Manual setup

If you prefer to configure manually instead of using the installer:

Claude Code

claude mcp add agent-inbox -- npx -y gsd-agent-inbox

Or add to ~/.claude/settings.json:

{
  "mcpServers": {
    "agent-inbox": {
      "command": "npx",
      "args": ["-y", "gsd-agent-inbox"]
    }
  }
}

Codex CLI

Add to ~/.codex/config.toml:

[mcp_servers.agent-inbox]
command = "npx"
args = ["-y", "gsd-agent-inbox"]
env = { }

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "agent-inbox": {
      "command": "npx",
      "args": ["-y", "gsd-agent-inbox"]
    }
  }
}

Gemini CLI

Add to ~/.gemini/settings.json:

{
  "mcpServers": {
    "agent-inbox": {
      "command": "npx",
      "args": ["-y", "gsd-agent-inbox"]
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "agent-inbox": {
      "command": "npx",
      "args": ["-y", "gsd-agent-inbox"]
    }
  }
}

Any other MCP client

Any client that supports stdio transport:

{
  "command": "npx",
  "args": ["-y", "gsd-agent-inbox"]
}

Build from source

git clone https://github.com/gsd-build/agent-inbox.git
cd agent-inbox
npm install
npm run build
npm start

Tools

Tool	What it does
`create_inbox`	Spin up a temporary email address. Optional `prefix` for readability, optional `name` for easy reference.
`check_inbox`	Check for messages. Returns subjects, bodies, and auto-extracted verification links.
`wait_for_email`	Poll until a matching email arrives. Filters by sender and subject. Auto-retries with backoff.
`verify_email`	One-shot verification: polls for confirmation email, extracts the link, visits it via HTTP. Three steps in one tool call.
`list_inboxes`	Show all active inboxes with names and providers.
`delete_inbox`	Destroy an inbox and its backing account.

Named inboxes

Give inboxes a name for easy reference across multiple tool calls:

create_inbox({ prefix: "signup", name: "main" })
wait_for_email({ address: "main", subject_contains: "confirm" })
delete_inbox({ address: "main" })

Skill

The installer can optionally add a skill file that teaches your AI agent when and how to use agent-inbox — so it reaches for the inbox tools automatically when it encounters auth flows, email verification, or sign-up testing.

To install the skill manually:

mkdir -p ~/.claude/skills/agent-inbox
curl -fsSL https://raw.githubusercontent.com/gsd-build/agent-inbox/main/skill/SKILL.md \
  -o ~/.claude/skills/agent-inbox/SKILL.md

How it works

Uses mail.tm as the primary provider with automatic fallback to 1secmail if mail.tm is down. No API keys or accounts required.

Fallback providers — if mail.tm fails, 1secmail kicks in automatically
Cleanup on exit — inboxes are deleted when the MCP server shuts down (SIGINT/SIGTERM)
Smart polling — wait_for_email retries with backoff (3s → 5s → 10s → 15s)
Link extraction — confirmation/verification URLs auto-detected via keyword matching

Limitations

Some services block disposable email domains. If sign-up is rejected, try a different service or provider.
Inboxes don't survive server restarts (in-memory only).
Text and HTML bodies only — no attachment support.

License

MIT

Available Tools

6 tools

check_inboxA

Check a temporary inbox for new messages. Returns subjects, bodies, and auto-extracted confirmation links.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	The email address or inbox name to check
`wait_seconds`	No	Seconds to wait before checking (default 5). Gives email time to arrive.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It states the tool returns subjects, bodies, and auto-extracted links, but it does not indicate whether the operation is read-only, what happens if the inbox is empty, error conditions, or any side effects. For a tool with no annotations, this is insufficient 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 extremely concise: two sentences that front-load the action and the return value. Every word adds value, no redundancy.

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?

While the description covers the basic function and output, it lacks context on prerequisites (e.g., inbox must exist via create_inbox), what happens on empty results, or any error handling. Given the lack of output schema and annotations, additional detail would improve 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?

Schema description coverage is 100%, so baseline is 3. The tool's description adds no additional meaning to the parameters beyond what the schema already provides (e.g., address purpose, wait_seconds default and range). The description focuses on the return value, not parameter semantics.

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 action 'Check a temporary inbox' and specifies what it returns: subjects, bodies, and confirmation links. This distinguishes it from sibling tools like create_inbox or delete_inbox, which are for management, and wait_for_email, which likely just waits without returning details.

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 using this tool to retrieve new messages from a temporary inbox, but it does not explicitly say when to use it versus alternatives like wait_for_email or verify_email. No prerequisites or exclusions are mentioned, limiting guidance for selecting the tool.

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

create_inboxA

Create a temporary email inbox. Returns a real email address that can receive emails from any service (Supabase, Resend, etc). Uses mail.tm with automatic fallback to 1secmail if mail.tm is down.

ParametersJSON Schema

Name	Required	Description	Default
`prefix`	No	Optional prefix for the email address (e.g. 'signup-test'). A timestamp is appended for uniqueness.
`name`	No	Optional human-friendly name for this inbox (e.g. 'test-1'). Use this name in other tools instead of the full address.

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description must fully convey behavior. It discloses that it uses mail.tm with automatic fallback to 1secmail. However, it does not mention whether the inbox is persistent, any rate limits, or what happens if both services are down.

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, each earning its place: first states the core function, second adds reliability details. It is front-loaded with the key action and avoids 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 tool with two optional parameters and no output schema, the description explains what it returns (a real email address) and the services used. It could mention the return format or error handling, but overall it provides sufficient context for an agent to use it correctly.

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?

Both parameters have descriptions in the schema (100% coverage). The description adds value by explaining that prefix appends a timestamp for uniqueness and that name can be used as a friendly identifier in other tools, which is not evident from the schema alone.

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 creates a temporary email inbox and returns a real email address. It distinguishes from siblings like check_inbox and delete_inbox by focusing on creation. It includes specific technical details about services used (mail.tm, 1secmail).

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 when to use (when you need a temporary inbox) but does not explicitly state when not to use or compare to siblings like verify_email. No exclusions or alternative guidance is provided.

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

delete_inboxA

Delete a temporary inbox and its account. Use after you're done with email verification.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	The email address or inbox name to delete

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided; description merely says 'delete' without elaborating on permanence, irreversibility, permissions, or error handling. Minimal behavioral context beyond the action.

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 sentences, front-loaded with purpose, no extraneous information. Extremely concise and well-structured.

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 deletion tool with one parameter, the description is adequate. It lacks mention of irreversibility or error behavior, but overall sufficiently guides the agent.

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% with a description for the parameter. The tool description adds 'temporary inbox and its account' but does not enhance parameter meaning beyond what schema already provides.

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 'temporary inbox and its account', distinguishing it from sibling tools like create_inbox, check_inbox, etc.

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?

Explicitly says 'Use after you're done with email verification', providing clear context for when to use the tool. However, no exclusions or alternatives are mentioned.

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

list_inboxesA

List all active temporary inboxes created in this session.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It discloses the tool lists active temporary inboxes, but does not mention any behavioral traits like read-only nature or session 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?

Single sentence of 9 words, front-loaded with essential information, no redundancy.

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?

Given no parameters or output schema, the description adequately covers the tool's purpose and scope. Could mention return format, but not critical.

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?

No parameters exist, so baseline is 4. The description adds meaning beyond empty schema by specifying 'active temporary inboxes created in this session'.

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 'List all active temporary inboxes' with verb and resource, and distinguishes from siblings like check_inbox, create_inbox, etc.

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 by stating scope ('in this session'), but lacks explicit guidance on when to use this vs alternatives like check_inbox for individual inboxes.

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

verify_emailA

One-shot email verification: polls for a confirmation email, extracts the verification link, and visits it via HTTP GET. Combines wait_for_email + link extraction + click in one tool call. Returns the HTTP status of the verification URL.

ParametersJSON Schema

Name	Required	Description
`address`	Yes	The email address or inbox name to poll
`from`	No	Filter: only match emails from this sender (substring match)
`subject_contains`	No	Filter: only match emails whose subject contains this string
`timeout_seconds`	No	Max seconds to wait for the email (default 60)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so the description must fully disclose behavior. It explains polling, extraction, and GET request, and specifies return value (HTTP status). However, it does not mention behavior on timeout (e.g., what happens if no email arrives), side effects (e.g., marking email as read), or error handling for failed extraction.

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 sentences, front-loaded with the core action, no redundant information. Every sentence serves a purpose, making it highly concise.

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 tool's complexity (multi-step, polling, extraction) and lack of annotations, the description is incomplete. It does not cover prerequisites (inbox must exist), failure modes (timeout, missing link), or side effects, which are critical for an agent to use it correctly.

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 the description adds limited value beyond the schema. It clarifies that 'from' and 'subject_contains' are filters and that timeout_seconds controls wait time, but this is already in the schema. The description does not add new parameter-specific guidance.

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 action: 'polls for a confirmation email, extracts the verification link, and visits it via HTTP GET.' It distinguishes from siblings like wait_for_email by noting it combines multiple steps into one tool.

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 implies usage for email verification flows by stating it combines wait_for_email, link extraction, and click. However, it does not explicitly state when not to use it or mention prerequisites like requiring the inbox to already exist.

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

wait_for_emailA

Poll an inbox until a matching email arrives. Retries with backoff. Returns the matching message with extracted links. Much better than manually calling check_inbox in a loop.

ParametersJSON Schema

Name	Required	Description
`address`	Yes	The email address or inbox name to poll
`from`	No	Filter: only match emails from this sender address (substring match)
`subject_contains`	No	Filter: only match emails whose subject contains this string (case-insensitive)
`timeout_seconds`	No	Max seconds to wait before giving up (default 60)

TDQS

A4/5.0

Behavior3/5

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

With no annotations, description covers key behaviors: polling, retries with backoff, and return of matched message with links. It does not detail side effects (e.g., whether emails are marked read) or failure behavior (timeout result), but is sufficient for a simple polling 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?

Two sentences with no wasted words. Front-loaded with purpose and immediately clarifies advantage over sibling. Every sentence adds value.

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?

Given 4 documented parameters and no output schema or annotations, the description covers the main function and output shape ('matching message with extracted links'). It lacks details on polling interval or backoff specifics, but is adequate for typical use.

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?

All parameters are documented in the input schema with descriptions. The tool description adds no extra meaning or usage hints for the parameters beyond what the schema provides, so baseline score of 3 applies.

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 it polls an inbox until a matching email arrives, with retries and backoff. It distills the core action and distinguishes from sibling tool check_inbox by promoting itself as a better alternative to manual looping.

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?

Explicitly advocates using this instead of check_inbox in a loop, providing clear context. However, it does not mention when not to use it or alternatives for other tasks like creating inboxes.

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

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: inbox lifecycle management (create, delete, list), message retrieval (check, wait, and verify). No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., create_inbox, wait_for_email), making it easy to predict functionality.

Tool Count5/5

Six tools is well-scoped for managing temporary inboxes and email verification, covering all necessary operations without bloat.

Completeness5/5

The surface covers the full workflow: create, check, wait, verify (wait+click), delete, and list. No obvious gaps for the domain.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

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

Zyntra - Temp e-mails MCP
io.github.dd77ss
Disposable inboxes for AI agents: create, wait for delivery, and extract email content or links.
Email Agent Orchestration
2
Temp Mail
io.temp-mail
Disposable email inboxes for AI agents — read messages and verification codes.
Email Testing & QA Tools
2
DevInbox
io.devinbox
Real email inboxes for AI agents: create inboxes, catch verification codes, extract OTPs, reply.
Email Autonomous Agents Developer Tools
1
machine-inbox A
com.machineinbox
Task-scoped email inboxes for AI agents: read mail, extract verification codes, and reply.
Email App Automation
111

Related MCP Servers

AgentMail MCP Server
Communication App Automation Developer Tools
kamath
F
license
Not graded
quality
D
maintenance
Enables creating temporary email inboxes and sending emails through the AgentMail API, allowing AI agents to manage email communications programmatically.
Updated a year ago (2025-08-29 09:07 UTC)
1
courier-mcp
Email Communication Autonomous Agents
antonioac1
A
license
Not graded
quality
C
maintenance
Enables AI agents to create disposable email inboxes and automatically extract OTPs, magic links, and verification codes from incoming emails.
Updated 3 months ago (2026-06-13 16:15 UTC)
24
MIT
AgentTemp MCPofficial
Email App Automation
agentinbox-in
A
license
Not graded
quality
C
maintenance
Enables AI agents to create temporary email inboxes and wait for OTPs, magic links, or password reset emails via AgentTemp's API, useful for automation and verification workflows.
Updated 2 months ago (2026-06-27 11:45 UTC)
15
MIT
TempMail OTP MCP Server
Email Testing & QA Tools Autonomous Agents
mifdlaldev
A
license
Not graded
quality
A
maintenance
Enables AI agents to generate temporary email addresses, receive emails, and automatically extract OTP codes and links from incoming messages for automation and testing workflows.
Updated a month ago (2026-07-23 15:48 UTC)
MIT

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/gsd-build/agent-inbox'

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

agent-inbox

Install

What it does

The problem

The fix

Manual setup

Claude Code

Codex CLI

Cursor

Gemini CLI

Windsurf

Any other MCP client

Build from source

Tools

Named inboxes

Skill

How it works

Limitations

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

AgentTemp MCPofficial

Latest Blog Posts

MCP directory API