Vexa

ai.vexa由 vexa.ai 发布官方发布者v0.12.27更新于 Oct 24, 2026

Meeting bot and transcripts for Google Meet, Teams and Zoom. Live or after, speakers labelled.

已验证Streamable HTTP可网页运行效率与工作流知识与记忆沟通与协作

概览

AI 生成的概览

Vexa 是远程 MCP 服务器,让助手派机器人加入线上会议、获取标注发言人的实时逐字稿,并操作会议知识工作区。

可以做什么
派机器人加入 Google Meet、Microsoft Teams、Zoom 或 Jitsi 会议,并可停止或查询机器人状态。读取实时逐字稿,内容标注发言人,会议进行中可持续轮询。列出会议与录音,录音音频存放在自己的存储中。在 Markdown 工作区上与代理对话,回复以流式方式返回。派发一次性代理任务、创建定时例行任务,或由事件触发代理。浏览并读取工作区的 Markdown 文件。
适用场景
当你希望助手把机器人送进 Google Meet、Teams 或 Zoom 会议,并获取实时且标注发言人的逐字稿时使用;也适合在会前会后整理知识库或工作区。只想做逐字稿、不需要代理功能时,也可单独使用。
运行要求
需要连接远程端点,并在 Authorization 请求头提供 Vexa API 密钥(Bearer 形式),密钥可从账户页面获取。托管的云服务需付费,新账户有少量免费额度;若要使用代理与知识工作区功能,需自行部署整套服务,并具备 Docker 或 Kubernetes 环境,逐字稿另需语音转文字服务。
安装前请注意
需要妥善保管 Authorization 中的 API 密钥,泄露可能导致他人代为使用并产生费用。派机器人加入会议会以参与者身份进入通话,可能被其他与会者看到,且会议内容会发送到托管的云服务。代理可写入工作区并创建定时或事件触发的任务,请确认变更范围与审批机制。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Vexa,将其添加到工作区。
  2. 连接 Authorization token 凭据。它们会被私密存储,绝不会在公开页面上展示。
  3. 为需要使用其工具的对话启用该服务。

Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。

交给智能体安装

把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体,或 SourceWeft 对话中。智能体会读取该服务器的安装指南,先向你展示发布者、端点和登录方式,经你同意后再把它添加到你的客户端。密钥不会写进任何命令。

阅读 https://sourceweft.com/mcp/ai.vexa%2Fvexa/install.md,并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前,先告诉我它的发布者、端点和登录方式,等我确认。不要把 API 密钥写进命令或我会提交的文件;问我密钥应从哪里获取。

查看智能体所依据的安装指南

其他 MCP 客户端

把它添加到你客户端的 mcpServers 配置中。

{
  "mcpServers": {
    "vexa": {
      "type": "http",
      "url": "https://api.cloud.vexa.ai/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_TOKEN>"
      }
    }
  }
}

README

[Vexa logo]

Vexa

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.)

[License: Apache 2.0] [Version] [Deploy] [Discord]

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 · Get an API key · Talk to the founder

Why Vexa

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:

  1. Vexa is in the meeting. A real bot joins Meet, Teams and Zoom — Jitsi offline-proven, live validation pending — and streams speaker-attributed transcripts live. That bot fleet is the genuinely hard part — every "chat with your docs" tool starts after a transcript exists. Vexa produces it.

  2. Your knowledge is files you own. Meetings compile into Markdown in a git repo — portable, diffable, greppable. Knowledge as code.

  3. Agents work it, safely. Sandboxed coding agents read and write that repo like developers — isolated ephemeral containers, no egress, thousands in parallel, on Docker or your Kubernetes.

Only here for the transcription API? It's a complete standalone product — send a bot, read the stream, ignore the agent lane entirely.


⚡ Quickstart

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:

bash
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.

Or self-host the whole stack

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 all pulls 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.

bash
git clone https://github.com/Vexa-ai/vexa.git && cd vexamake all      # full Docker Compose stack — seeds .env, pulls the images (bot included),              # prints your API key + URLs. Contributors: `make dev` builds from this checkout.

When make all finishes it prints your key and URLs:

text
  Terminal UI : http://localhost:13000     # the web workbench  API gateway : http://localhost:18056     # the API  API key     : vxa_…

Explore in the Terminal (the fast path)

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:

  • Send a bot — paste a Meet / Zoom / Teams / Jitsi URL; a bot joins as a participant.
  • Watch the transcript stream in live, speaker-attributed, draft-then-confirmed.
  • Chat with your workspace — ask an agent that has every captured meeting as context, and watch it commit what you decide.

Or drive it over the API

bash
export API_KEY=vxa_...export API_BASE=http://localhost:18056
# WIN 1 — send a bot into a live call, then read the transcript as it streamscurl -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"
# WIN 2 — ask an agent that has your whole workspace as context (answer streams back as SSE)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.


🧩 How it works

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.


⚙️ The agentic runtime

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.

  • Isolated. Every dispatch gets its own container: no egress except brokered tools, and only its granted workspaces exist in its filesystem — enforced by the substrate, not by the agent. Agents never run in the control plane.
  • Ephemeral. A container lives while it works and is reaped on idle; continuity is a session file in the workspace. Sub-second starts, thousands in parallel.
  • Orchestration-agnostic. One 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)
processa child process, no Docker socket required✅ Available
k8sa 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.


🧠 Agents & your workspace

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.

  • Multiplayer. Team-shared, attributed workspaces — not one person's private notes.
  • Automated. The bot captures the call; the transcript compiles itself in.
  • Safe by design. Agents are untrusted and enforce nothing themselves. You, in chat, write directly (git is the undo); untrusted input — an email, a web page — runs propose-only: the agent suggests, a human approves, trusted code applies. Irreversible effects are always gated.

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.


🖥️ The Terminal: AI-augmented meetings

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.

  • An agent in your meeting, with your knowledge. Open a live call: the transcript streams speaker-attributed, and the agent has the live conversation and your workspace in context. Ask mid-call "what did we promise them last time?" — or research a person, company, or contract the moment it comes up, grounded in your wiki.

  • Knowledge built on meetings — and between them. Every planned meeting gets an agent that prepares the brief before (who's coming, history, open threads — it interviews you for what it can't know) and processes the transcript after. Arrive prepared, leave with the wiki updated.

  • Sharing. Invite colleagues into a workspace — same wiki, attributed. Share a meeting with its attendees — they get the real-time feed, not a recording link after the fact.

  • Collaborative, AI-augmented meetings. Prep a shared workspace together; during the call, humans edit the brief while agents stream the transcript in and work the knowledge — one room, human and AI participants on the same files.


📖 How-to recipes

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).

bash
curl -N -X POST "$API_BASE/agent/chat" -H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \  -d '{"prompt":"Brief me on the Acme account: every meeting, the open decisions, and the next step."}'

🌅 Brief me every morning — an unattended agent on a cron schedule that commits to your workspace.

bash
curl -X POST "$API_BASE/agent/routines" -H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \  -d '{"name":"Morning brief","cron":"0 8 * * 1-5",       "prompt":"Brief me from overnight activity — new meetings, decisions, follow-ups due. Write brief/today.md.",       "run_now":true}'

📝 Report after every meeting — dispatch a one-shot agent when a call ends (or a routine that sweeps recent meetings).

bash
curl -X POST "$API_BASE/agent/invocations" -H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \  -d '{"runner":"claude-code","workspaces":[{"id":"u_jane","mode":"rw"}],"trigger":"scheduled",       "start":{"entrypoint":{"inline":"Write a report for the meeting that just ended: summary, decisions, action items with owners."}}}'

📧 Triage incoming email (safely) — an event-triggered agent that gets the mailbox read-only and can only propose actions as cards; a human approves before anything is written or sent.

bash
curl -X POST "$API_BASE/agent/events" -H "X-API-Key: $API_KEY" -H "Content-Type: application/json" \  -d '{"name":"email.received","source":{"uri":"mailbox://u_jane/INBOX/AB12CD"},       "plan":{"prompt":"Triage this email into tasks; propose a record for each action item and a draft reply."}}'

During the call — stream the live transcript with GET /agent/meeting/stream and ask your agent about it in the chat. Vexa runs no model of its own during a meeting: there is one intelligence and it is your agent. See Status.


🚀 Deployment options

Two ways to run Vexa, one codebase:

1. Personal / dev — Docker on your Mac, Linux, or Windows machine. Single container (make lite — the all-in-one Vexa Lite image) or the full Compose stack (make all). Reuse your Claude subscription: workers run the official claude CLI against your own Pro/Max credential, which is a covered, credit-metered use under Anthropic's terms for a personal deployment — your subscription, your turns, your machine. See Model credentials & licensing for the exact terms mapping (Anthropic's Agent SDK plan-usage article is the primary source). You get the full service — bots, transcripts, agents, Terminal — on the subscription you already pay for.

2. Cloud — Helm on Kubernetes / OpenShift, scalable to thousands of users. The chart in deploy/helm deploys the same control plane with RUNTIME_BACKEND=k8s: every bot and every agent is its own Kubernetes workload (a bare Pod per dispatch), so capacity is your cluster's scheduler, not a bigger box — built multi-tenant and multiuser from the start. One compliance rule when you go multiuser: other users' turns must run on an API key (Commercial Terms), never a personal subscription credential — the licensing page spells out the boundary, and Settings → Models enforces per-user/global credential resolution. K8s backend status is tracked honestly in Status.


🏠 Deploy & configure

make all brings up the full stack via Docker Compose on one Linux host — each service in its own container, bound to loopback:

ServiceRole
gateway :18056the one front door — auth, scopes, routing
terminal :13000the web workbench (proxies /ws → gateway)
meeting-apibots, transcripts, recordings
agent-apithe agent control plane — dispatch, chat, routines, events
runtimespawns bot + agent containers on demand
admin-api · redis · postgres · storagekeys · bus + scheduler · metadata · recordings (versitygw: plain files in a local volume)
  • Runtime backend — RUNTIME_BACKEND=docker (default) or k8s (a Pod per dispatch).
  • Transcription is a separate GPU unit — make all runs GPU-free; stand up the STT service (faster-whisper, OpenAI-compatible) from deploy/transcription on any GPU box and point .env at it. Or use a free hosted token at vexa.ai/account while testing.
  • Bring your own inference — point the agent at your own LLM endpoint; no inference leaves the network.
  • Air-gapped — everything in-VPC, zero egress — the posture the regulated verticals require.
  • Targets — make all (pulls) · make dev (builds from this checkout) · make lite · make probe (full-journey smoke) · make down · make help. Expose the Terminal via a TLS reverse proxy for production; full guide in the docs.

🆚 How Vexa is different

The crowded "AI second brain / self-hosted knowledge base" space is full of excellent tools for reasoning over documents you already have. None of them join a live meeting — they consume transcripts other tools produced. That's the whole point: capture is the moat, and it sits upstream of where a document-RAG tool's architecture even starts.

Against the tools developers actually weigh for meeting capture:

CapabilityVexaHosted APIs (e.g. Recall.ai)DIY (Whisper + your own bot)
Self-hosted / own your data✅❌ their cloud✅
Real-time transcript API✅✅🟡 build it
Joins Meet + Teams + Zoom + Jitsi✅ 3 production · 🟡 Jitsi🟡 varies❌ enormous effort
Speaker attribution✅✅🟡 build it
Knowledge as files you own✅❌🟡 build it
Agents over your workspace✅❌❌
Open source✅ Apache-2.0❌✅

Vexa is the one combination the others don't offer: a permissively-licensed (Apache-2.0) meeting-bot-API server that is self-hosted × real-time × multi-platform × knowledge-you-own. And it's complementary to the document-RAG and "second brain" tools — feed them Vexa's clean, attributed transcripts and let them do what they're good at.

The full field — including Attendee (the other meeting-bot API, source-available under the Elastic License 2.0, which does not permit providing it to third parties as a hosted or managed service) and the local-notetaker tools — is mapped honestly, trade-offs and all, in How Vexa compares.


🏦 For regulated enterprises

For banks, healthcare, government, and anyone in a regulated industry, the meeting-AI question isn't "which cloud" — it's "how do we get this without a cloud." Vexa is air-gapped meeting intelligence — the sovereign alternative to Microsoft Copilot — built for exactly that buyer.

You don't compete with a notes app here — you replace Microsoft 365 Copilot and Zoom AI Companion on the axes they structurally can't move:

Microsoft 365 Copilot / Zoom AI CompanionVexa
DeploymentVendor cloud onlyYour cloud, your VPC, or fully air-gapped
ModelsVendor-hosted, fixedBring your own — local or hosted LLMs
Commercial modelRented, per-seat subscriptionOwned — Apache-2.0, no per-seat tax
AdaptableGeneric; no custom vocabulary; vendor roadmap queueYour engineers extend it directly — domain vocabulary, underserved languages, custom workflows
Meeting platformsTeams-only / Zoom-onlyMeet + Teams + Zoom (+ Jitsi, live validation pending)
Data controlTransits the vendor's cloudNever leaves your perimeter
ExtensibilityClosed black boxOpen source, API-first

What that means in practice:

  • Air-gapped — fully offline, your infrastructure, your models. Nothing phones home.
  • Adaptive — your engineers implement requirements directly: domain vocabulary, underserved languages, custom workflows. No vendor feature queue.
  • Owned, not rented — deploy once, extend without asking permission. No per-seat tax.
  • Scales inside your walls — thousands of isolated agents in parallel on Docker or your Kubernetes/OpenShift cluster.

Evaluate it for your org — the artifacts a security review asks for, in this repo:

ArtifactWhat it answers
architecture.calm.jsonmachine-readable architecture (FINOS CALM) — every service and data flow, drift-gated in CI
SECURITY.mdhow to report a vulnerability
security-insights.ymlOpenSSF Security Insights manifest
license-exceptions.jsonlicense gating: Category-A permissive deps, exceptions explicit
LICENSEApache-2.0

Full review page: Security & compliance in the docs.

Regulated banks and Fortune-500s run Vexa fully air-gapped on their own OpenShift and local LLMs today.


📡 API reference

Two APIs behind the gateway, authenticated with X-API-Key. Base URL: http://localhost:18056 (self-host) or https://api.cloud.vexa.ai (hosted).

Meetings API — capture; usable standalone:

MethodEndpointDescription
POST/botsSend a bot into a meeting (platform, native_meeting_id, bot_name, language, task, optional transcribe_enabled / recording_enabled)
GET/transcripts/{platform}/{native_meeting_id}Fetch the real-time transcript (poll while live)
GET/bots/statusList running bots
DELETE/bots/{platform}/{native_meeting_id}Stop / remove the bot
GET/meetings · /recordingsList meetings; list recordings (audio in your own storage)

Agent API — the control plane, under the /agent/* prefix (identity is derived from your key, server-side):

MethodEndpointDescription
POST/agent/chatChat over your workspace — streams SSE (message-delta, tool-call, commit, done, error)
POST/agent/invocationsDispatch a one-shot agent (e.g. a post-meeting report)
POST/agent/routinesCreate a scheduled (cron) agent routine
POST/agent/eventsFire an integration event that dispatches an agent (e.g. email triage)
GET/agent/workspace/tree · /agent/workspace/fileBrowse and read your Markdown workspace

platform ∈ google_meet · teams · zoom · jitsi. The gateway also serves an MCP endpoint at /mcp for agent clients (docs). Full reference: docs.vexa.ai.

v0.12 note: live bot-control — PUT /bots/{…}/config (change language/task mid-call) and POST /bots/{…}/speak (TTS into the call) — plus WebSocket streaming are not yet wired in the open-core stack and return 404 today. So do POST /agent/meeting/{start,process}, the removed in-product meeting copilot. Send-a-bot, stop, status, transcripts, recordings, the live transcript feed, agent chat, routines, and events are live.


🗺️ Status & roadmap

Honest state of the 0.12 line (mirrors the status page — never aspirational):

CapabilityState
Bot joins Meet / Teams / Zoom✅ Production
Bot joins Jitsi Meet (meet.jit.si + self-hosted)🆕 Built & offline-proven; live validation pending
Real-time transcription (Whisper) + speaker attribution✅ Production — attribution is not guaranteed: the binder publishes an empty speaker rather than guessing (~4–7% of rows under heavy crosstalk)
Redis transcript streaming✅ Production
Recordings to your own object storage (S3; versitygw in Lite and Compose)✅ Available
Runtime — Docker backend (container per workload)✅ Production
Agent chat / routines / events over your workspace✅ Built & proven live
Workspace — git Markdown / OKF kg/ bundle🟡 core proven; bucket-backed store landing
Runtime — Kubernetes backend (Pod per dispatch)✅ Lifecycle + per-mount isolation; Helm in deploy/helm
Live transcript feed as the call runs (+ agent chat over it)✅ Built & proven live
Calendar sync (ICS) · planned meetings · scheduled auto-join✅ Production
Shared workspaces & shared meetings (invites, real-time feed)✅ Built & proven live
Agent chat during a live meeting (live transcript + workspace in context)✅ Built & proven live
WebSocket transcript multiplex🔵 Planned (poll today)
At-rest encryption (workspace · transcript · tokens)🔵 Planned
Mid-call bot config / speak🔵 Returns 404 in open-core

✅ Production · 🟡 In progress · 🔵 Planned


🤝 Community & contributing

  • Docs — docs.vexa.ai
  • Discord — discord.gg/Ga9duGkVz9
  • Roadmap — the board, grouped by contributor lane, with milestones as the version gates.
  • Contributing — how delivery works: prepared issues with acceptance tables that guarantee merge, and human validation credited as a first-class contribution (one page, law and how-to together).
  • Contributor rights — one rights choice plus DCO for individuals; private, head-bound authorization when an employer or client owns the work.
  • Issues & PRs — welcome. See SECURITY.md to report vulnerabilities.
  • Obsidian: obsidian-vexa-bridge turns completed meetings into Obsidian notes or a knowledge graph, a third-party adapter; see the docs.

Vexa is built in the open. If you self-host it, extend it, or run it air-gapped somewhere interesting, we'd love to hear about it.


📄 License

Apache-2.0. Own it, run it, fork it, ship it. It's an investment, not a rental.

来源:README.md,提交 18e7ac1

工具

0
该服务器需要 API 密钥等凭据,因此 SourceWeft 无法在没有凭据的情况下读取其工具,也未收录。

版本历史

1
  1. v0.12.27最新Sep 16, 2026

评分

已满足适用检查项的 85%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通必需25 分
  • 已声明认证方式必需10 分
  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分