Vexa
by Vexa-ai
Meeting bot and transcripts for Google Meet, Teams and Zoom. Live or after, speakers labelled.
Runs in the cloud★ 2,949Apache-2.0Updated 2 months ago
Install
Openagentemail MCP
Overview
Description from the maker (original English)
Unlimited agent mailboxes — create identities, read/wait for mail, extract OTPs, send email.
PopNx MCP’s three pillars
These three are never merged into one score: opinions, measurements and popularity are different things.
- User voiceiNo reviews yetReviews open together with accounts in a later step
- Our basic checksi1 of 1 passedChecked from public information; code not scanned yet
- UsageiNot measured yet★ –
What you can do with it
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
- Connection: Runs on your computer
- Transport: stdio
- Category: Chat & email
- You need to fill in: OPENAGENTEMAIL_API_KEY
Install
Pick the AI app you use, then copy the settings.
Before you install
- Basic checks: 1 of 1 passed
- Runs on your computer with your user’s permissions (files, network, apps).
- You fill in yourself:
OPENAGENTEMAIL_API_KEY,OPENAGENTEMAIL_API_URL
Values marked secret are keys to your account. Never share them or paste them into a chat.
You need
- npmNode.js installed (for the npx command)
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"openagentemail": {
"command": "npx",
"args": [
"-y",
"@openagentemail/mcp"
],
"env": {
"OPENAGENTEMAIL_API_KEY": "your-value",
"OPENAGENTEMAIL_API_URL": "your-value"
}
}
}
}Run this in your terminal
claude mcp add openagentemail --env OPENAGENTEMAIL_API_KEY=your-value --env OPENAGENTEMAIL_API_URL=your-value -- npx -y @openagentemail/mcpFill in the empty values before running it.
Or copy the settings yourself
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"openagentemail": {
"command": "npx",
"args": [
"-y",
"@openagentemail/mcp"
],
"env": {
"OPENAGENTEMAIL_API_KEY": "your-value",
"OPENAGENTEMAIL_API_URL": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Or copy the settings yourself
Paste into .vscode/mcp.json in your project
{
"servers": {
"openagentemail": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@openagentemail/mcp"
],
"env": {
"OPENAGENTEMAIL_API_KEY": "your-value",
"OPENAGENTEMAIL_API_URL": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
Values you fill in
- Bearer key for the openagent.email API — best: the identity token (oa_…) returned by POST /v1/identities.
OPENAGENTEMAIL_API_URLenvBase URL of the openagent.email API.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
What it can do
Runs on your computer; the tool list appears in your AI app after you install it.
Basic checksi
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
- ✓ Pass
Maker matches the repo
The registry name was verified with the GitHub account openagentemail, which owns the repo
- … Not checked yet
Still maintained
We have not read this repo from GitHub yet
- … Not checked yet
Has a licence
We have not read this repo from GitHub yet
- – Not applicable
Endpoint responds
This one runs on your computer; there is no internet endpoint
- – Not applicable
Sign-in with OAuth
Runs on your computer and uses local settings instead
- … Not checked yet
No hidden instructions in tool descriptions
Runs on your computer; we can only read tool lists from internet endpoints
Compared with others in Chat & emaili
- More stars than 0% of the other 1771 servers in this category
- Published to the registry more recently than 41% of the other 1771 servers in this category
- Basic checks equal to or better than 100% of the other 1771 servers in this category
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
Common questions
Is Openagentemail MCP safe?
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
What keys or codes does it need?
You need to fill in: OPENAGENTEMAIL_API_KEY
Does it run on my computer or in the cloud?
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
Is it still maintained?
The GitHub repo last changed –, and the latest version (0.10.0) reached the registry 38 days ago.
Which apps can use it?
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.
What can I use instead?
In the same category: Vexa, emailmd, MCP WhatsApp Cloud
Alternatives
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
emailmd
by anypost
Render markdown into email-safe HTML, lint drafts for deliverability problems, and preview emails.
Computer or cloud★ 1,385MITUpdated 31 days ago
Install
MCP WhatsApp Cloud
by codespar
MCP server for WhatsApp Cloud API (Meta) — messages, media, and templates via Graph API
Runs on your computer★ 277MITUpdated 5 months ago
Install
README from the maker
Open the README
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
OpenAgentEmail
Open communication and task handoffs for AI agents. Self-hosted email, task threads, approvals, and webhooks over MCP and REST —for the agents you already use. Bring your own agents. Keep control of the work.
Get started · Try a task handoff · Documentation · Architecture · 简体中文
See it work
Give an agent an address. Send it a task. Read its progress and result in the same thread. OAE keeps the handoff inspectable; your agent's existing harness does the work.
Watch the handoff recording (MP4) — about 47 seconds. The video is linked, not embedded inline. Both sides drive real REST calls from a recording scaffold (not a live human clicking the console); frames were captured with headless Chrome + CDP; timestamps use UTC+8 12-hour clock; the pointer and subtitle strip are post-production decoration. Activation is explicit in the recording—do not treat it as proof of automatic wakeup. Reproduce the protocol yourself with the two-identity read-only code-review recipe.
sequenceDiagramparticipant A as Requester agent participant O as OpenAgentEmail participant B as Recipient agent A->>O: Create a task for B B->>O: Read the task when activated B->>O: Report working Note over B: Review in its own environment B->>O: Report completed with a result A->>O: Read the result and history
See the existing email and OTP interface
This repository image demonstrates the email capability, not an Agent orchestration console. Task-board product images appear under Human visibility below.
Why OpenAgentEmail?
Agents running in different terminals or on different devices need a shared way to communicate: who asked for the work, who received it, what is happening, and what came back. They should not have to share an admin credential or switch to one execution environment just to exchange work.
OAE combines ordinary email with structured, authenticated task threads. Use it as an agent mailbox, an inspectable task handoff layer, or both. Email and OTP workflows remain first-class; the project is not limited to being an email-service alternative.
What you can do today
| Capability | What it gives you | Boundary |
|---|---|---|
| Agent identities | Addresses on your managed domain(s), with individual identity tokens | Logical identities over a catch-all mailbox, not unlimited physical mailboxes |
| Email and messaging | Send/read mail, extract OTP codes and links, wait for a match | SMTP acceptance is not recipient delivery |
| Task handoffs | Named recipient, state history, structured results and direct parent-child links | No automatic worker selection or descendant scheduling |
| Approvals | Record a specified reviewer's approval or rejection | The decision does not execute the action |
| Notifications and webhooks | Human alerts and outbound event delivery to your integration | Webhooks are opt-in; delivery is not proof an agent consumed the task |
| Human visibility | Inspect mail, tasks, identities and notifications in the dashboard | Access depends on the session's identity and permissions |
These are real product screenshots from a controlled capture (anonymized). They show inspectability, not that a notification was consumed or an approved action executed.
REST, HTTP MCP and the stdio MCP wrapper expose these operations. Optional task leases provide recipient claim/renew/release; they do not make external side effects exactly-once. See the tool reference.
Quickstart
Already have an instance?
Ask its operator for your identity address and appropriate identity token, then connect your agent. You do not need to deploy another mailserver. Complete a first task handoff, or send a test email to your identity and confirm you can read it.
Deploy a new instance
Start the guided setup:
npx -y @openagentemail/setupThe setup CLI guides deployment and client configuration. Choose the mail backend that fits your environment:
| Deployment | Use it when | Prerequisites |
|---|---|---|
| Bundled mailserver | You want to operate your own mail stack | Docker Compose, a domain, DNS configuration and reachable inbound SMTP; outbound port 25 or a relay |
| API-only | A provider already hosts your domain | Docker Compose, a catch-all mailbox, IMAP/SMTP credentials and permission to send as the identity addresses |
Keep the API's localhost binding unless you deliberately configure an SSH tunnel or HTTPS reverse proxy. Mail certificates and HTTPS for the API are separate concerns. Do not publish a bare HTTP API carrying tokens.
After deployment, verify the path you actually chose:
Bundled mailserver. This stack owns mail.$DOMAIN, the mail DKIM selector, and TLS on ports 465/993. Run the doctor against that layout:
sudo ./deploy/doctor.shIt checks DNS, port access, certificates and notification prerequisites for the bundled stack. It still does not log in over IMAP/SMTP or send a round-trip email.
API-only (your own mail provider). Skip deploy/doctor.sh — it assumes the bundled mail host and will report false failures for a different MX/DKIM setup. Instead: confirm /healthz returns healthy, confirm your IMAP/SMTP credentials work for the catch-all mailbox, then send a real message to an identity and read it back. Only then try the task recipe. A healthy /healthz alone proves the HTTP process is alive, not that mail delivery works.
Existing api-data volume: one-time non-root migration (#93)
The API runtime image runs as the bun user (uid/gid 1000), not root. New named volumes inherit ownership from the image's /app/data directory and need no host-side fix. Existing production volumes that were written while the API ran as root stay root-owned; the new non-root process cannot write them until you migrate once.
Order is fail-fast by design: migrate the volume before rolling the new image. Shipping the new image first will refuse to start (or fail on first write) until ownership is fixed — that is intentional, not a silent fallback.
- Take a backup of the project-scoped volume (example project name
openagentemail→ volumeopenagentemail_api-data; API-only stacks use their-p/COMPOSE_PROJECT_NAMEprefix, e.g.oae-alpha_api-data). - Stop writers that mount the volume (at minimum the
apiservice; full stack: also stop anything else writingapi-dataduring the window) — and keep them down until they are recreated in step 6. Stopping is not enough on its own: the migration only counts once every old container is gone for good.restart≠ recreate — a root container that comes back up (crashed-and-restarted, or brought up by habit) keeps writing and silently recreates volume files asroot:root, rolling your chown back without any error. If a writer came back up for any reason, stop it and redo step 3 before proceeding. - One-shot chown to the runtime user:
# Replace <project>_api-data with your real volume name (docker volume ls).docker run --rm -v _api-data:/data alpine \ sh -c 'chown -R 1000:1000 /data'
- Spot-check ownership before bringing services back:
docker run --rm -v <project>_api-data:/data alpine \sh -c 'ls -ln /data | head'
Expect uid/gid columns to show 1000 / 1000 for migrated paths.
- Read back the migration on the volume — must pass:
docker run --rm -v <project>_api-data:/data alpine \sh -c 'find /data ! -user 1000 | head'
Expect no output: zero files still owned by a non-1000 user.
- Pull/build the new images, then verify the API image declares the runtime user before starting anything. Build the whole project (
docker compose buildwith no service name) — or at minimumapiandntfy-provisiontogether: they share one Dockerfile, and the--force-recreatebelow re-runs the one-shot ntfy-provision container too, so it must come from the same non-root image batch. A stale root-based provision image re-running here would write the volume as root and roll your migration back — the same failure this runbook exists to prevent.
docker inspect <new-api-image> --format '{{.Config.User}}'Expect bun (uid 1000) — never empty/root.
Only then start everything (docker compose up -d --force-recreate or your usual deploy path).
Do not reverse this order. Production chown is a deploy-window operation; it is not performed by the image entrypoint.
Deploy-window recreate gotchas (measured 2026-09-21)
- `--force-recreate ` follows the dependency chain. Measured on the reference host: recreating
apialso recreatedmailserveralongapi→mailserver→provision(andntfypullsntfy-provision) — healthy, ~11s, no loss, but unintended. To recreate only the named services, add--no-deps; full-project builds keep the plain form. - Measure override attribution — do not assume it. Before editing or removing any override, run
docker compose configagainst three configurations: base alone, base + each override, and compare the resolved output field by field. On the reference host (2026-09-21) this distinguished two siblings:docker-compose.override.ymlwas a zero-contribution no-op (its patches had long been absorbed into the base file) and was removed with a timestamped backup, whilecompose.override.yamlis live and must be kept (adds the loopback binding and widens allowed ports). A "Found multiple override files" warning at recreate time is the cue to run this check. Scope note: override auto-merging happens only on default-file invocations — deployments selecting files explicitly (e.g. API-onlydocker compose -f compose.api-only.yaml ...) auto-merge no override at all and must pass every override explicitly.
ntfy non-root upgrade (#278)
ntfy now runs as UID 1000 and listens on container port 2587. If an existing deploy previously ran ntfy as root, chown its d
Only the beginning is shown; read the rest in the repo