Using Google Colab MCP with a Temporary Email API

The Gap in the MCP Tool Ecosystem

The Model Context Protocol is doing something important: it is turning external capabilities into first-class tools that AI agents can discover and invoke without custom integration code. Google Colab MCP takes this further — your agent can now execute Python code in a real Colab runtime as a tool call. Search, web browsing, code execution, structured data retrieval: these are all becoming standardized tool surfaces.

But there is a gap that almost every real-world automation workflow hits eventually.

Agents still cannot reliably interact with email.

This is not an oversight. Email is structurally awkward to expose as a tool. It requires live SMTP infrastructure, async delivery timing, MIME parsing, and some mechanism to match a received message to a specific agent session. None of that is obvious to implement, and existing solutions — shared inboxes, Gmail IMAP, mocked flows — break under real conditions.

This article shows how to close that gap. You will see how a temporary email API exposes real inbox capabilities as MCP tools, how to call those tools from Google Colab using the Python MCP client, and why the MCP approach is meaningfully different from calling the REST API directly.

---

What MCP Actually Changes

The difference between calling a REST API and using an MCP tool is not just syntax. It is a change in who is responsible for knowing what is available.

With a REST API, the agent (or the human building the agent) has to know the endpoint, the method, the request shape, and the response schema before writing a single line of code. The knowledge is baked into the integration layer — usually as custom glue code, a wrapper function, or a prompt that tells the LLM what to call.

With MCP, the agent calls tools/list and gets back a structured description of every available capability: names, descriptions, input schemas, and output shapes. The agent can reason about which tools to use without any prior instruction. An agent runtime like Claude Desktop, AutoGen, or LangGraph can consume an MCP server it has never seen before and immediately know what it can do.

This matters for agent design in a concrete way: it removes the coupling between the agent's reasoning and the specific API surface of each service. You do not need to update your prompt or your wrapper code when the underlying service changes. You add a server to the configuration, and the capability becomes available.

For email specifically, this means the agent does not need to know anything about SMTP, MIME, or polling intervals. It calls create_signup_inbox, gets an address, uses it, and calls wait_for_verification_email. The infrastructure knowledge stays in the server.

---

The Missing Tool: Email

Email shows up as a dependency in a surprisingly large fraction of real-world automation:

• Account signups that require a confirmation link before the account activates
• Two-factor authentication flows where the second factor is an OTP sent to the registered address
• Subscription confirmations that gate access to an API key or resource
• Password resets that block account recovery until the user clicks a link

Each of these is a hard stop for an autonomous agent. The agent can complete every other step of the workflow. Then it hits "check your email" and either stalls waiting for human input or fails entirely.

The workarounds that teams reach for do not hold up under scrutiny:

Shared inboxes ([e-mail]) introduce race conditions immediately. Ten parallel test runs create ten verification emails into one inbox. There is no clean way to correlate which code belongs to which session.

Gmail IMAP requires OAuth2 credentials, refresh token logic, and ongoing credential management. App passwords get blocked by workspace policies. IMAP polling adds unpredictable latency. And you are parsing raw RFC 2822 MIME with all its multipart structure on your end — it breaks every few months.

Mocking the email step means your agent never exercises the real flow. When you need the agent to interact with a third-party service that controls its own email delivery, there is nothing to mock.

Manual intervention defeats the purpose. An agent that pauses for a human to check an inbox is not automating the flow; it is just moving the manual step around.

What agents actually need is a programmable inbox: created on demand, accepting real SMTP traffic, queryable via a structured interface, and gone when the job is done.

---

The MCP Email Tools

UnCorreoTemporal exposes exactly this infrastructure as an MCP server. The server runs over streamable-HTTP at https://uncorreotemporal.com/mcp and authenticates callers with a Bearer token (Authorization: Bearer uct_your_key_here).

It exposes six tools. Here they are with their actual input schemas, taken directly from the server implementation:

create_signup_inbox

Input:  service_name (str), ttl_minutes (int, optional)
Output: {inbox_id, email, expires_at, service_name}

Creates a live temporary inbox. The email field is the SMTP address — human-readable, like [e-mail]. The inbox is live immediately and expires automatically at expires_at.

wait_for_verification_email

Input:  inbox_id (str), timeout_seconds (int=90), poll_interval_seconds (int=3),
        subject_contains (str, optional), from_contains (str, optional)
Output: {message_id, status, ...} or {status: "timeout"}

Blocks until a matching email arrives or the timeout is exceeded. The subject_contains and from_contains filters let you wait for a specific sender or subject line without reading everything.

get_latest_email

Input:  inbox_id (str), mark_as_read (bool=False)
Output: full message object with body_text, body_html, from_address, subject, received_at

Retrieves the most recent message in the inbox, with full body content. The server handles MIME parsing — body_text and body_html are already decoded strings.

extract_otp_code

Input:  message_text (str, optional), inbox_id (str, optional), message_id (str, optional),
        otp_length_min (int=4), otp_length_max (int=8)
Output: {otp_code, candidates}

Extracts a numeric OTP from message text. You can pass message_text directly or let the tool fetch the message itself via inbox_id + message_id.

extract_verification_link

Input:  message_text (str, optional), inbox_id (str, optional), message_id (str, optional),
        preferred_domains (list[str], optional)
Output: {verification_link, candidates}

Extracts the most likely verification URL from message text. Use preferred_domains to bias toward a specific service's domain when multiple links are present.

complete_signup_flow

Input:  service_name (str), timeout_seconds (int=90), ttl_minutes (int, optional),
        subject_contains (str, optional), from_contains (str, optional),
        preferred_domains (list[str], optional)
Output: {status, email, verification_link, otp_code, verification_message, ...}

An end-to-end composite tool: creates the inbox, waits for the email, extracts both the verification link and the OTP in a single call. Returns status: "success" when at least one of the two was found, status: "partial_success" if the email arrived but neither could be extracted, or status: "timeout" if nothing came through.

This is the key tool for agents. Instead of orchestrating five separate calls, the agent calls one tool and gets back everything it needs to complete a verification flow.

---

Using Email as a Tool in Colab

Google Colab gives you a Python runtime that is already connected to the internet and has pip available. The mcp Python package supports streamable-HTTP transport, which means you can connect to the UnCorreoTemporal MCP server directly from a Colab cell.

Install the client:

# Cell 1
!pip install mcp httpx -q

Connect to the server:

# Cell 2
import asyncio
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

UCT_API_KEY = "uct_your_key_here"  # get one at uncorreotemporal.com
MCP_URL = "https://uncorreotemporal.com/mcp"

async def list_tools():
    async with streamablehttp_client(
        url=MCP_URL,
        headers={"Authorization": f"Bearer {UCT_API_KEY}"}
    ) as (read, write, _):
        async with ClientSession(read, write) as session:
            await session.initialize()
            tools = await session.list_tools()
            return [t.name for t in tools.tools]

tools = asyncio.run(list_tools())
print(tools)
# ['create_signup_inbox', 'wait_for_verification_email', 'get_latest_email',
#  'extract_otp_code', 'extract_verification_link', 'complete_signup_flow']

The agent discovers what is available without any hardcoded knowledge. Now use the composite tool:

# Cell 3 — create an inbox ready for a signup flow
import json

async def create_inbox(service_name: str):
    async with streamablehttp_client(
        url=MCP_URL,
        headers={"Authorization": f"Bearer {UCT_API_KEY}"}
    ) as (read, write, _):
        async with ClientSession(read, write) as session:
            await session.initialize()
            result = await session.call_tool(
                "create_signup_inbox",
                {"service_name": service_name, "ttl_minutes": 15}
            )
            return json.loads(result.content[0].text)

inbox = asyncio.run(create_inbox("GitHub"))
print(f"Inbox address: {inbox['email']}")
print(f"Expires at:    {inbox['expires_at']}")
# Inbox address: [e-mail]
# Expires at:    2026-03-20T10:45:00Z

Use the address to register with the target service, then retrieve everything in one call:

# Cell 4 — after triggering the signup email, call complete_signup_flow

async def run_complete_flow(service_name: str):
    async with streamablehttp_client(
        url=MCP_URL,
        headers={"Authorization": f"Bearer {UCT_API_KEY}"}
    ) as (read, write, _):
        async with ClientSession(read, write) as session:
            await session.initialize()

            # One call: creates inbox, waits for email, extracts link + OTP
            result = await session.call_tool(
                "complete_signup_flow",
                {
                    "service_name": "GitHub",
                    "timeout_seconds": 90,
                    "ttl_minutes": 15,
                }
            )
            return json.loads(result.content[0].text)

flow = asyncio.run(run_complete_flow("GitHub"))
print(f"Status:  {flow['status']}")
print(f"Email:   {flow['email']}")
print(f"Link:    {flow['verification_link']}")
print(f"OTP:     {flow['otp_code']}")
# Status:  success
# Email:   [e-mail]
# Link:    https://github.com/users/confirm-email?token=eyJh...
# OTP:     None  (GitHub uses links, not OTPs)

The complete_signup_flow tool returns both verification_link and otp_code — the caller does not need to know which one the service uses. If it is an OTP-based service, otp_code will be populated. If it sends a link, verification_link will be populated. The agent handles whichever is non-null.

---

MCP vs REST: The Design Difference

Here is the same flow written against the REST API directly:

# REST approach
import requests, re, time

BASE = "https://uncorreotemporal.com/api/v1"
HEADERS = {"Authorization": "Bearer uct_your_key_here"}

# Step 1: create inbox
resp = requests.post(f"{BASE}/mailboxes", params={"ttl_minutes": 15}, headers=HEADERS)
data = resp.json()
address = data["address"]
session_token = data["session_token"]

# Step 2: poll for messages (manual loop)
msg_headers = {"X-Session-Token": session_token}
deadline = time.time() + 90
message = None

while time.time() < deadline:
    msgs = requests.get(
        f"{BASE}/mailboxes/{address}/messages",
        headers=msg_headers
    ).json()
    if msgs:
        full = requests.get(
            f"{BASE}/mailboxes/{address}/messages/{msgs[0]['id']}",
            headers=msg_headers
        ).json()
        message = full
        break
    time.sleep(3)

# Step 3: extract link manually
if message:
    match = re.search(r"https?://[^\s]+verify[^\s]+", message["body_text"])
    link = match.group(0) if match else None

This works, and it is what a Colab notebook using raw requests looks like. But notice what the developer had to build:

• A polling loop with timeout management
• Session token tracking per inbox
• Manual regex extraction for links and OTPs
• Knowledge of the API endpoint structure

Compare to the MCP approach:

# MCP approach — same outcome, zero glue code
result = await session.call_tool(
    "complete_signup_flow",
    {"service_name": "GitHub", "timeout_seconds": 90, "ttl_minutes": 15}
)
flow = json.loads(result.content[0].text)
link = flow["verification_link"]

The MCP approach is not just shorter. It is structurally different in a way that matters at scale:

	REST	MCP
Tool discovery	Manual (docs, prompts)	Automatic (tools/list)
Polling	Developer implements	Server implements
Extraction logic	Developer implements regex	Tool handles OTP + link extraction
Session management	Developer tracks tokens	Server manages per-call auth
Composability	One-off integration	Reusable across all MCP runtimes
Agent integration	Custom per-framework	Standard across Claude, AutoGen, LangGraph

The REST API is the right choice when you are building a custom pipeline where you control every step. MCP is the right choice when the consumer is an agent that needs to reason about what it can do and orchestrate the steps dynamically.

---

Architecture: What Makes This Work

The tools describe what agents can do. The architecture explains why they are reliable.

When any service sends a verification email to a UnCorreoTemporal address, here is what happens:

External sender → AWS SES (spam/virus filtering)
                         ↓ SNS webhook
              POST /api/v1/ses/inbound
                         ↓
              core/delivery.deliver_raw_email()
               ┌──────────┴──────────┐
               ↓                     ↓
         PostgreSQL             Redis pub/sub
         (message stored)    (channel: mailbox:{address})
                                      ↓
                             WebSocket push to browser
                             /ws/inbox/{address}

Key properties:

Real SMTP delivery. In production, emails travel through AWS SES. There is no simulation, no test mode — any sender on the internet can deliver to a UnCorreoTemporal address, and it works. The wait_for_verification_email tool is waiting for messages that actually arrived via SMTP, not mocked locally.

Parsed at ingest. deliver_raw_email() parses the RFC 2822 message, extracts body_text and body_html, stores everything in PostgreSQL. By the time a tool call reads the message, the raw MIME has already been processed. The agent gets clean strings.

Ephemeral by design. Every inbox has an expires_at timestamp. A background worker soft-deletes expired mailboxes automatically. The agent creates an inbox, uses it, and never needs to clean up — it just stops calling it.

Parallel-safe. Each inbox is isolated. 50 parallel agent sessions creating 50 inboxes never share state. There are no race conditions on the inbox side.

The MCP server itself is stateless per request. Each tool call creates its own database connection, performs the operation, and closes. The server holds no inbox state between calls — everything lives in PostgreSQL.

---

Why This Matters for Autonomous Agents

The steady-state for AI agents is increasing autonomy over longer-horizon tasks. An agent that can write code, search the web, call APIs, and execute logic in Colab is already impressive. But it hits a ceiling the moment it needs to interact with a service that uses email as a control point.

That ceiling is structural, not technical. The agent is not missing intelligence — it is missing infrastructure. Give it a programmable inbox as a tool, and the ceiling disappears:

• Autonomous account provisioning: The agent registers on external services, confirms the email, continues the workflow — no human in the loop.
• CI/CD email testing: Every build creates fresh inboxes, triggers signup flows against the production login system, asserts verification emails arrived, tears down automatically.
• Parallel agent runs: 20 sessions, 20 inboxes, zero shared state. Each agent operates in complete isolation.
• Research workflows: An agent registers for access to a dataset, receives and processes the confirmation, downloads the resource, and the inbox expires when the job is done.

The common thread is that email is not optional in these flows. It is the coordination mechanism that external services use to verify identity and gate access. Agents that cannot handle it are excluded from a large class of real-world tasks.

The MCP interface makes this accessible without infrastructure overhead. You point your agent at the server, it discovers the tools, and email becomes a capability — not a special case.

---

Conclusion

Google Colab MCP and similar execution environments are expanding what agents can do. But code execution is only one piece of real-world automation. Email is another, and it has been the missing piece for longer than it should have been.

The UnCorreoTemporal MCP server gives agents six tools for handling email flows: create an inbox, wait for a message, read its content, extract an OTP, extract a verification link, or do all of it in one call with complete_signup_flow. The server runs over streamable-HTTP and works with any MCP-compatible runtime — including a Colab cell with the mcp Python library installed.

The infrastructure is real: SMTP delivery via AWS SES, PostgreSQL-backed message storage, Redis pub/sub for real-time events, ephemeral inboxes that expire automatically. There is no simulation. The emails that arrive are emails that actually traveled across the internet.

If you are building agents that need to interact with real-world services, the inbox is one call_tool away. Start at uncorreotemporal.com.