What can you do with this server?

This server enables AI agents to automate temporary email inbox management and email verification workflows for service signups. * Create temporary email inboxes (create_signup_inbox): Generate a disposable email address for a target service (e.g., GitHub) with an optional time-to-live (TTL) in minutes. * Wait for verification emails (wait_for_verification_email): Poll an inbox until a verification email arrives or a timeout is reached, with optional filters for sender and subject. * Retrieve the latest email (get_latest_email): Fetch the full content and metadata of the most recent email in an inbox. * Extract OTP codes (extract_otp_code): Parse a numeric one-time password from an email body with configurable min/max code length. * Extract verification links (extract_verification_link): Identify and return the most likely verification URL from an email, with optional preferred domain filtering. * Run a complete signup flow (complete_signup_flow): Execute the full end-to-end workflow in a single call — creating an inbox, waiting for the verification email, and extracting both the verification link and OTP code.

Which integrations are available for this server?

Facilitates autonomous account creation and email verification for GitHub by managing temporary inboxes and extracting verification links or OTP codes from received emails.

de en es ja ko ru zh

UnCorreoTemporal

by francofuji

Overview Schema Related Servers Score Discussions

TypeScript

Remote

UCT Demo

uncorreotemporal-mcp

MCP Badge

MCP server for UnCorreoTemporal, focused on autonomous signup and email verification workflows.

Glama

Architecture Demo

AI Agent
   |
   | MCP
   v
Temporary Email MCP Server
   |
   v
UnCorreoTemporal API

Related MCP server: waw-mcp

Remote Connection (No Installation)

Connect directly to the public endpoint — no local install needed:

{
  "mcpServers": {
    "uncorreotemporal-mcp": {
      "url": "https://uncorreotemporal.com/mcp"
    }
  }
}

The public endpoint is free to use for testing. For production workloads, set your own UCT_API_KEY via local install.

Installation

Claude Code

claude mcp add uncorreotemporal -e UCT_API_KEY=uct_your_key_here -- uvx uncorreotemporal-mcp

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "uncorreotemporal": {
      "command": "uvx",
      "args": ["uncorreotemporal-mcp"],
      "env": {
        "UCT_API_KEY": "uct_your_key_here"
      }
    }
  }
}

Get your API key at uncorreotemporal.com.

Quickstart (30 seconds)

uvx uncorreotemporal-mcp

Or run local project version:

UCT_API_KEY=uct_your_key_here \
uv run uncorreotemporal-mcp

Minimal Workflow Example

inbox = await create_signup_inbox("github")
email = await wait_for_verification_email(inbox["inbox_id"])
link = await extract_verification_link(
    inbox_id=inbox["inbox_id"],
    message_id=email["message_id"],
)

Public Tools

create_signup_inbox
wait_for_verification_email
get_latest_email
extract_otp_code
extract_verification_link
complete_signup_flow

New v1 tool: `complete_signup_flow`

Runs:

create inbox
wait verification email
extract verification link + OTP

Input:

{
  "service_name": "github",
  "timeout_seconds": 90,
  "poll_interval_seconds": 3,
  "subject_contains": "verify",
  "from_contains": "noreply",
  "preferred_domains": ["github.com"],
  "ttl_minutes": 30
}

Output:

{
  "status": "success",
  "inbox_id": "agent42@uncorreotemporal.com",
  "email": "agent42@uncorreotemporal.com",
  "verification_message": {
    "message_id": "msg-1",
    "subject": "Verify your email",
    "from_address": "noreply@example.com",
    "received_at": "2026-03-08T11:30:00Z"
  },
  "verification_link": "https://example.com/confirm?t=abc",
  "otp_code": "483920",
  "link_candidates": ["https://example.com/confirm?t=abc"],
  "otp_candidates": ["483920"]
}

status can be success, partial_success, or timeout.

Tool I/O summary

`create_signup_inbox(service_name, ttl_minutes?)`

Returns:

{
  "inbox_id": "agent42@uncorreotemporal.com",
  "email": "agent42@uncorreotemporal.com",
  "expires_at": "2026-03-08T12:00:00Z",
  "service_name": "github"
}

`wait_for_verification_email(inbox_id, timeout_seconds?, poll_interval_seconds?, subject_contains?, from_contains?)`

Returns:

{
  "status": "received",
  "message_id": "msg-1",
  "received_at": "2026-03-08T11:30:00Z",
  "subject": "Verify your account",
  "from_address": "noreply@example.com",
  "timeout_seconds": 90
}

`get_latest_email(inbox_id, mark_as_read?)`

Returns full message body and metadata.

`extract_otp_code(message_text? | inbox_id+message_id, otp_length_min?, otp_length_max?)`

Returns:

{
  "otp_code": "483920",
  "candidates": ["483920"]
}

`extract_verification_link(message_text? | inbox_id+message_id, preferred_domains?)`

Returns:

{
  "verification_link": "https://example.com/confirm?t=abc",
  "candidates": ["https://example.com/confirm?t=abc"]
}

Configuration

Environment variables:

UCT_API_KEY (required)
UCT_API_BASE (optional, default: https://uncorreotemporal.com)
UCT_HTTP_TIMEOUT_SECONDS (optional, default: 20)
UCT_MCP_TRANSPORT (optional, stdio by default; also supports streamable-http and sse)
UCT_MCP_HOST (optional, default: 0.0.0.0)
UCT_MCP_PORT (optional, default: 8000)
UCT_MCP_PATH (optional, default: /mcp)

Important: inbox_id == email address.

Examples

See /examples:

simple_workflow.py
openai_agent_signup.py
langchain_agent_signup.py
agent_creates_account.py

Run dry-run:

uv run python examples/simple_workflow.py --dry-run

Docker

Build:

docker build -t uncorreotemporal-mcp .

Run stdio mode:

docker run --rm -i \
  -e UCT_API_KEY=uct_your_key_here \
  uncorreotemporal-mcp

Run streamable-http mode:

docker run --rm -p 8000:8000 \
  -e UCT_API_KEY=uct_your_key_here \
  -e UCT_MCP_TRANSPORT=streamable-http \
  -e UCT_MCP_PATH=/mcp \
  uncorreotemporal-mcp

Breaking Changes

Removed legacy low-level tools:

create_mailbox
list_mailboxes
get_messages
read_message
delete_mailbox

Migration map:

create_mailbox -> create_signup_inbox
get_messages + read_message -> wait_for_verification_email + get_latest_email
multi-step signup orchestration -> complete_signup_flow

Directory listing assets

Prepared listing payloads are in /directory-listings for:

modelcontextprotocol/servers
mcp.so
awesome-mcp

Public endpoint deployment

Deployment templates for https://uncorreotemporal.com/mcp are in /deploy.

Development

uv run pytest
uv run uncorreotemporal-mcp

Available Tools

6 tools

complete_signup_flowB

End-to-end signup helper: create inbox, wait for email, extract link and OTP.

ParametersJSON Schema

Name	Required	Description	Default
`service_name`	Yes
`timeout_seconds`	No
`poll_interval_seconds`	No
`subject_contains`	No
`from_contains`	No
`preferred_domains`	No
`ttl_minutes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only outlines the process without mentioning side effects, timeouts, security, or error handling. Information about what happens to the created inbox after extraction or behavior on failure is missing.

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 concise sentence that efficiently conveys the tool's composite nature. However, it lacks structure such as bullet points or sections that could improve readability, but it's not verbose and gets the point across.

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 has 7 parameters and an output schema, the description is incomplete. It does not mention return values (though output schema exists), nor does it explain how parameters influence behavior. The composite nature is stated, but many contextual details are omitted.

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

Parameters1/5

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

The schema has 0% parameter description coverage, and the tool description does not explain any parameter meaning or usage. Parameters like 'service_name', 'timeout_seconds', and 'subject_contains' are left entirely undocumented, failing to add value beyond the schema structure.

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 as an 'End-to-end signup helper' and lists the specific steps it performs: create inbox, wait for email, extract link and OTP. This distinguishes it from sibling tools which are individual steps, making the composite nature explicit.

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 the tool is for completing the signup flow in one call, but it does not explicitly state when to use this composite tool versus using the individual sibling tools separately. No guidance on when not to use or alternatives is provided.

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

create_signup_inboxC

Create a temporary signup inbox for a target service.

ParametersJSON Schema

Name	Required	Description	Default
`service_name`	Yes
`ttl_minutes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits but only mentions 'temporary' without elaborating lifecycle, persistence, or side effects. Important details like what happens when ttl_minutes is null are missing.

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 single sentence is concise and front-loaded with the action verb. However, it sacrifices clarity on parameters and usage, which could be expanded slightly without losing 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 sibling tools and the presence of an output schema, the description fails to explain where this tool fits in a signup flow (e.g., that it should be used before waiting for emails). The temporary nature and lifespan are not clarified.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description provides no explanation of the two parameters. 'service_name' and 'ttl_minutes' remain undefined, forcing the agent to infer meaning from the tool name 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 the action (create), resource (temporary signup inbox), and target (for a service). It effectively differentiates from sibling tools like complete_signup_flow or extract_otp_code.

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 is provided on when to use this tool versus alternatives such as wait_for_verification_email. The description lacks any context about prerequisites or typical workflow placement.

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

extract_otp_codeC

Extract a numeric OTP code from an email body or message reference.

ParametersJSON Schema

Name	Required	Description	Default
`message_text`	No
`inbox_id`	No
`message_id`	No
`otp_length_min`	No
`otp_length_max`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only states the core function, missing details on side effects, error handling (e.g., if no OTP found), or required permissions. This is insufficient for a tool that processes user data.

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 a single short sentence, which is concise but lacks any structure (e.g., sections, bullet points). It conveys the purpose efficiently but at the cost of omitting useful details.

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 has 5 parameters (0 required, all undocumented), an output schema (not described in the description), and sibling tools, the description is incomplete. It does not explain how to use the parameters, what the output contains, or how this tool differs from siblings in detail.

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

Parameters1/5

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

The schema description coverage is 0%, and the description adds no parameter details. It loosely references 'email body' and 'message reference' but does not explain the function of message_text, inbox_id, message_id, otp_length_min, or otp_length_max. The agent has no guidance on how to use these parameters.

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 specifies the verb 'Extract' and the resource 'numeric OTP code from an email body or message reference'. It distinguishes from sibling tools like extract_verification_link, which extracts a link rather than a code.

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 that this tool should be used when a numeric OTP code is needed from an email, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites.

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

extract_verification_linkC

Extract the most likely verification link from an email.

ParametersJSON Schema

Name	Required	Description	Default
`message_text`	No
`inbox_id`	No
`message_id`	No
`preferred_domains`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.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 burden. It only states 'extract', implying read-only but not explicitly. Missing details on side effects, required permissions, or return behavior beyond extraction.

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 concise (one sentence) but lacks structure and necessary details. While short, it sacrifices completeness for brevity, making it less useful.

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 absence of annotations, multiple optional parameters, and existence of similar siblings, the description is too incomplete. An agent cannot reliably determine how to use this tool without additional context.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no information about the four parameters (message_text, inbox_id, message_id, preferred_domains). The agent gets no help understanding what each parameter does or how they relate.

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 extracts a verification link from an email, distinguishing it from sibling tools like extract_otp_code which extracts OTP codes. However, the phrase 'most likely' is vague and could be more specific.

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 is provided on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or how it relates to siblings like wait_for_verification_email.

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

get_latest_emailB

Read and return the latest full email in an inbox.

ParametersJSON Schema

Name	Required	Description	Default
`inbox_id`	Yes
`mark_as_read`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations were provided, so the description bears full burden. It does not disclose whether the email is marked as read (despite a mark_as_read parameter), side effects, or read-only nature. The simple description 'Read and return' is insufficient for behavioral clarity.

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 sentence with no wasted words. However, it is borderline too terse, missing critical context that would not significantly lengthen it.

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 tool is simple (two parameters, output schema present), but the description does not connect it to sibling tools in the email verification flow, nor explain what 'full email' means or how the output is structured. It is adequate for a minimal tool but lacks contextual richness.

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?

With 0% schema description coverage, the description should add meaning to parameters. It only mentions 'inbox' generically, not explaining inbox_id or mark_as_read. The schema itself lacks descriptions, and the tool description does not compensate.

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 reads and returns the latest email in an inbox, using specific verbs and resources. It distinguishes itself from siblings like extract_otp_code or wait_for_verification_email.

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 like search_emails or when not to use it. The description lacks context for appropriate use cases.

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

wait_for_verification_emailC

Wait until a verification email arrives or timeout is reached.

ParametersJSON Schema

Name	Required	Description	Default
`inbox_id`	Yes
`timeout_seconds`	No
`poll_interval_seconds`	No
`subject_contains`	No
`from_contains`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description should fully disclose behavior. It hints at polling but doesn't explain that poll_interval_seconds is used, what happens on timeout (error or null), or if actions like marking as read occur. Minimal disclosure.

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 a single sentence, which is concise but too brief. It could be restructured to include key parameters and behavior while staying efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters (one required), no schema descriptions, no annotations, and a potentially complex polling behavior, the description is severely incomplete. It fails to equip the agent with enough context to use the tool correctly.

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

Parameters1/5

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

Schema coverage is 0% and the description adds no parameter information. It does not explain the meaning of inbox_id, timeout_seconds, poll_interval_seconds, subject_contains, or from_contains, leaving the agent to infer from names 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 the tool waits until a verification email arrives or timeout is reached, which distinguishes it from sibling tools like get_latest_email (no waiting) and extract_otp_code (parsing).

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 like get_latest_email or when polling is preferred over direct extraction. No exclusions or context for when not 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.

6 tool updatesv0.1.0Apr 2, 2026
- First observedcomplete_signup_flow
- First observedcreate_signup_inbox
- First observedextract_otp_code
- First observedextract_verification_link
- First observedget_latest_email
- First observedwait_for_verification_email

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: create_signup_inbox sets up the inbox, wait_for_verification_email monitors for arrival, get_latest_email retrieves content, extract_otp_code and extract_verification_link parse specific elements, and complete_signup_flow orchestrates the workflow. The separation between extraction tools (OTP vs. link) and monitoring vs. retrieval is unambiguous.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case throughout (e.g., create_signup_inbox, extract_otp_code, wait_for_verification_email). The naming is predictable and readable, using clear action verbs aligned with each tool's function without any stylistic deviations.

Tool Count5/5

With 6 tools, the count is well-scoped for the server's purpose of handling temporary email signup workflows. Each tool earns its place by covering distinct steps in the process, from inbox creation to email extraction, without being overly sparse or bloated.

Completeness5/5

The tool set provides complete coverage for the email-based signup domain: it supports creating an inbox, waiting for and retrieving emails, extracting both OTP codes and verification links, and an end-to-end orchestration tool. There are no obvious gaps, and agents can handle the full lifecycle without dead ends.

Maintenance

ActivityInactive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Zyntra - Temp e-mails MCP A
app.zyntra.mcp
MCP server for e-mail testing: create disposable inboxes, wait for delivery, and extract e-mail content or links - all from your AI agent or test automation workflow. Get a free API key on https://app.zyntra.app/
Developer Tools 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
Temp MailOAuth
io.temp-mail
Disposable email inboxes for AI agents — read messages and verification codes.
Email Testing & QA Tools
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

Related MCP Servers

useblip/email
App Automation Customer Support Email
blipemail
A
license
A
quality
C
maintenance
MCP server for disposable email — create inboxes, receive emails, and extract OTP codes. Let your AI agent sign up for services, wait for verification emails, and extract codes autonomously.
Updated 5 months ago (2026-03-24 15:49 UTC)
7
61
1
MIT
waw-mcp
Email Browser Automation Autonomous Agents
Revens2
A
license
Not graded
quality
B
maintenance
Gives AI agents a real email identity, OTP reading, autonomous signup, and MCP server registry via a single stdio MCP connection.
Updated 3 months ago (2026-06-16 10:21 UTC)
25
MIT
identity-mcp
Email Security Autonomous Agents
purple-flea
A
license
Not graded
quality
D
maintenance
MCP server that gives AI agents disposable email addresses and real phone numbers with automatic OTP extraction and self-destructing identities.
Updated 6 months ago (2026-02-21 20:08 UTC)
MIT
zerodrop-mcp
CI/CD & DevOps Developer Tools
zerodrop-dev
A
license
A
quality
A
maintenance
Provides disposable email inboxes for AI agents to automatically receive and extract OTPs and magic links, enabling seamless email verification during autonomous workflows.
Updated 2 months ago (2026-07-20 19:59 UTC)
3
86
MIT

Appeared in Searches

Search for 'Misarmail'

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/francofuji/uncorreotemporal-mcp-server'

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

uncorreotemporal-mcp

Architecture Demo

Remote Connection (No Installation)

Installation

Claude Code

Claude Desktop (claude_desktop_config.json)

Quickstart (30 seconds)

Minimal Workflow Example

Public Tools

New v1 tool: complete_signup_flow

Tool I/O summary

create_signup_inbox(service_name, ttl_minutes?)

wait_for_verification_email(inbox_id, timeout_seconds?, poll_interval_seconds?, subject_contains?, from_contains?)

get_latest_email(inbox_id, mark_as_read?)

extract_otp_code(message_text? | inbox_id+message_id, otp_length_min?, otp_length_max?)

extract_verification_link(message_text? | inbox_id+message_id, preferred_domains?)

Configuration

Examples

Docker

Breaking Changes

Directory listing assets

Public endpoint deployment

Development

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

Claude Desktop (`claude_desktop_config.json`)

New v1 tool: `complete_signup_flow`

`create_signup_inbox(service_name, ttl_minutes?)`

`wait_for_verification_email(inbox_id, timeout_seconds?, poll_interval_seconds?, subject_contains?, from_contains?)`

`get_latest_email(inbox_id, mark_as_read?)`

`extract_otp_code(message_text? | inbox_id+message_id, otp_length_min?, otp_length_max?)`

`extract_verification_link(message_text? | inbox_id+message_id, preferred_domains?)`