emailmd
Render markdown into email-safe HTML, lint drafts for deliverability problems, and preview emails.
Description from the maker (original English)
Meeting bot and transcripts for Google Meet, Teams and Zoom. Live or after, speakers labelled.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Open Claude Desktop → Settings → Connectors → Add custom connector, and paste this address
https://api.cloud.vexa.ai/mcpRun this in your terminal
claude mcp add --transport http vexa https://api.cloud.vexa.ai/mcp --header 'Authorization: your-value'Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"vexa": {
"url": "https://api.cloud.vexa.ai/mcp",
"headers": {
"Authorization": "your-value"
}
}
}
}Paste into .vscode/mcp.json in your project
{
"servers": {
"vexa": {
"type": "http",
"url": "https://api.cloud.vexa.ai/mcp",
"headers": {
"Authorization": "your-value"
}
}
}
}Authorization secret required HTTP headerValues marked secret are keys to your account. Never share them or paste them into a chat.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
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 5, 2026
The registry name was verified against the domain vexa.ai (the registry checks domain ownership)
Code last changed yesterday
Uses Apache-2.0
Responded in 920 ms (HTTP 401)
Needs a key or token that you copy and paste yourself
Needs the server’s tool list first; this check starts in the next step
Compared only with servers in this prototype, not the whole registry.
It passed 4 of 5 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.
You need to fill in: Authorization
It runs in the maker’s cloud. Connect over the internet with nothing to install, but what you send passes through the maker’s servers.
The GitHub repo last changed yesterday, and the latest version (0.12.27) reached the registry 2 months ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. It connects by URL, so apps that accept remote MCP servers work too, such as ChatGPT in developer mode.
In the same category: emailmd, MCP WhatsApp Cloud, Gmail MCP Server
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
Render markdown into email-safe HTML, lint drafts for deliverability problems, and preview emails.
MCP server for WhatsApp Cloud API (Meta) — messages, media, and templates via Graph API
Lets AI read, search and draft emails in your Gmail, signed in with your Google account through a local settings file.
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.
Open-source meeting bots and real-time transcription — cloud or fully self-hosted.
A bot joins your Google Meet, Microsoft Teams, and Zoom calls and streams speaker-attributed transcripts in real time — through our API or one *you* host — then feeds sandboxed agents that build a Markdown knowledge base your team owns. Apache-2.0, air-gap-ready. (Jitsi: join + capture offline-proven, live validation pending — #883.)
[vexa.ai](https://vexa.ai) runs Vexa 0.12 for meeting bots and transcription. Sandboxed knowledge agents are self-hosted only — self-host Vexa to run the full stack.
[Connect your agent](https://vexa.ai/connect?utm_source=github&utm_medium=readme) · [Get an API key](https://vexa.ai/start?utm_source=github&utm_medium=readme) · [Talk to the founder](https://cal.com/dmitrygrankin/web)
Every meeting-AI tool you can buy sends your conversations to *their* cloud and rents you access back. Vexa inverts that: run the stack yourself, point it at your own models, own what your meetings become.
No one else has all three:
Only here for the transcription API? It's a complete standalone product — send a bot,
read the stream, ignore the agent lane entirely.
Just want a bot in a meeting? Use the hosted service — no install. Sign in at vexa.ai/signin, copy your key from your account page, and send a bot:
curl -X POST "https://api.cloud.vexa.ai/bots" \
-H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \ -d '{"platform":"google_meet","native_meeting_id":"abc-defg-hij","bot_name":"Vexa"}'
New accounts get $2 of free bot credit, no card required — about 6 hours of bot time at $0.30/hr (pricing). More calls: Send a bot.
That is also how you get the agent plane, which is not part of the hosted service. Self-host on one host, then explore it in the Terminal or drive it over the API. Linux (Ubuntu 24.04) is the production target; a Mac with Docker Desktop works fine for a local evaluation — everything runs in containers either way.
Prerequisites — make, Docker engine ≥ v26 (make all checks), and transcription: a free token at vexa.ai/account, or self-host the (GPU) transcription unit for a fully air-gapped setup. By default POST /bots requires STT and answers 503 when it is missing (make all warns when the credentials block in .env is empty). Capture-only is an explicit opt-out: {"transcribe_enabled": false} on the spawn (or set TRANSCRIBE_ENABLED=false for the deployment).
Build machine:
make allpulls the published, release-validated images — no build, so a
modest box is fine.
make lite(the single-container all-in-one image) is lighter still. Building
from this checkout instead (
make dev, for contributors) wants 8 vCPUs and 16 GB RAM.
git clone https://github.com/Vexa-ai/vexa.git && cd vexa
make all # full Docker Compose stack — seeds .env, pulls the images (bot included),
make dev builds from this checkout.
When make all finishes it prints your key and URLs:
Terminal UI : http://localhost:13000 # the web workbench
API gateway : http://localhost:18056 # the API API key : vxa_…
The Terminal is the way to see what Vexa can do. Open `http://localhost:13000` — you're already signed in to a self-host account. From the workbench you can, with no curl:
export API_KEY=vxa_...
export API_BASE=http://localhost:18056
curl -X POST "$API_BASE/bots" \ -H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \ -d '{"platform":"google_meet","native_meeting_id":"abc-defg-hij","bot_name":"Vexa"}'
curl -H "X-API-Key: $API_KEY" "$API_BASE/transcripts/google_meet/abc-defg-hij"
curl -N -X POST "$API_BASE/agent/chat" \ -H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \ -d '{"prompt":"What did we decide in my last meeting?"}'
platform is google_meet · teams · zoom · jitsi; native_meeting_id is the code from the join URL. The agent reply streams as Server-Sent Events — message-delta frames carry the text, commit frames mark anything it recorded into your workspace.
One gateway, two domains — Meetings (capture) and Agents (work the knowledge) — both running on the same runtime: the engine that spawns every bot and every agent in its own sandboxed container.
A bot and an agent are the same `runtime.v1` workload — isolated, ephemeral, reaped on idle — so the machinery already proven by thousands of meeting bots is exactly what runs your agents. Every arrow stays inside your network.
A CLI coding agent is just a process on Linux. The runtime makes that a multi-tenant, sandboxed execution layer safe to point at real business data — the same engine that already spawns Vexa's meeting bots in production.
runtime.v1 lifecycle, pluggable substrate — the same dispatch runs identically across:Backend (RUNTIME_BACKEND) | A workload is… | State |
|---|---|---|
| `docker` (default) | its own container via the Docker socket — brought up with make all | ✅ Shipped (open core) |
| `process` | a child process, no Docker socket required | ✅ Available |
| `k8s` | a bare Pod (kubectl run --restart=Never), scheduled across a cluster | ✅ Lifecycle + per-mount workspace isolation; Helm chart in deploy/helm |
Same control plane, same worker — only how the container is created changes. One laptop to a Kubernetes/OpenShift cluster, inside your walls.
Capture is the front door; agents make the knowledge compound. Every meeting compiles into your workspace — a git repo of Markdown (an Open Knowledge Format kg/ bundle) that agents (Claude Code, Codex, …) read and write like developers work a codebase.
This is Andrej Karpathy's LLM Wiki
pattern, run as a team service. The idea: don't RAG over raw documents — where the model
rediscovers everything from scratch on every question — have agents compile sources into
structured, interlinked markdown entity pages (people, companies, projects, decisions) so
knowledge compounds. Vexa builds that wiki for you from the richest source there is: your
meetings. Each call is ingested into entity pages; agents keep them current between calls; every
answer starts from what your team already knows — on your own servers.
Agents work *any* workspace; a meeting is just one trigger of four — chat, schedule (cron), event (e.g. incoming email), finished meeting. Meetings themselves are scheduled work: connect your calendar (ICS) and planned meetings appear with attendees — bots auto-join, agents prepare before the call and process after it.
Status (honest): capture, transcription, and speaker attribution are production; the
agent dispatch core is built and proven live end-to-end. What's still landing is tracked in
Status.
0.12 ships a new Terminal UI built to put the backend's scale — thousands of bots and agents — to work on your actual week. It opens on your meetings: coming up, live now, to review.
Each is a complete path to one outcome over the Agent API. Full guides at docs.vexa.ai.
💬 Chat with your workspace — ask an agent that has every meeting, email, and note as context; trusted chat can also record a decision (a git commit).
curl -N -X POST "$API_BASE/age