# Reported issues for Vexa Pod holds 17 of 23 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects. Back to [Vexa](/mcp/vexa). ## Most discussed ### GET /mcp (SSE stream) intermittently 503s at api-gateway, never reaching vexa-mcp — POST works 116/116 ## Incoming from hosted prod — `GET /mcp` (SSE stream) intermittently 503s at the api-gateway, never reaching the MCP service Observed on vexa **0.10.6.3.14** in hosted production, 2026-07-18. Low volume but a clean, reproducible split. ### The numbers Over a 15-minute window, counting the same requests at the gateway and at the MCP service: | method | api-gateway saw | vexa-mcp saw | |---|---|---| | `POST /mcp` | 104 × 200, 12 × 202 | 104 × 200, 12 × 202 — **matches exactly** | | `GET… [Read the thread](https://github.com/Vexa-ai/vexa/issues/795) · 2026-07-18 · closed · 10 comments ### mcp: GET /mcp with a VALID session id never starts a response — the SSE stream produces nothing and sse-starlette's ping never fires ## Origin Measured during the #795 fix (PR #920, gateway MCP front door). **This is a different point of introduction from #795** — #795's 503 was manufactured by the 0.10 gateway's buffered client; this one is upstream of the gateway entirely, in the MCP service. Filed separately so the gateway fix isn't credited with resolving it. ## Observation (measured, not inferred) A `GET /mcp` carrying a **valid `mcp-session-id`** receives **no response head at all**: - **70 seconds with nothing** —… [Read the thread](https://github.com/Vexa-ai/vexa/issues/921) · 2026-07-22 · closed · 7 comments ### MCP server is not reachable through the gateway — /mcp 404s, so no external MCP client can use the documented tools ### What happened The MCP service runs and works, but there is no route to it from outside the compose network, so an external MCP client (Claude Desktop, an IDE, any other MCP host) cannot connect to a Vexa deployment. **The server itself is healthy.** Talking to it directly on its own published port, it completes a real MCP handshake and advertises nine tools: ``` POST http://localhost:18010/mcp {"method":"initialize", …} → {"result":{"protocolVersion":"2025-03-26",… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1035) · 2026-08-06 · open · external user · 5 comments ### test(mcp): the meeting MCP server has never been witnessed by a real MCP client — only mocked FastAPI-route tests ## Where we are (honest) The meeting MCP brick (`core/meetings/services/mcp/`) exposes four tools + prompts over the MCP transport: `parse_meeting_link`, `request_meeting_bot`, `list_meetings`, `get_meeting_transcript` (`src/vexa_mcp/app.py:181-341`, mounted via `FastApiMCP` + `mcp.mount_http()`). Its tests (`tests/test_app.py`, `tests/test_mcp_surface.py`) are real and green — but **every one drives the FastAPI routes directly against an `httpx.MockTransport` fake gateway**. None of them… [Read the thread](https://github.com/Vexa-ai/vexa/issues/888) · 2026-07-21 · open · 4 comments ### [DEV] Coding-agent onboarding: one command to store the key, then full capability awareness ## The gap A technical evaluator was handed a Vexa API key during a live call and told to point his coding agent at it. Everything after that was friction, and none of it was the product failing: - The agent asked **where to put the key**. There is no Vexa convention, so it invented one (`~/.zshrc`, a name of its own choosing) after interrogating the user. - The agent **did not know the MCP server exists**. It went looking for REST endpoints and console pages by guesswork. - It dispatched… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1341) · 2026-08-28 · open · 3 comments ### [Bug] MCP for MS Teams does not work because agent does not know it needs a passcode ## What happened? When an agent (or user) uses the MCP tool **request_meeting_bot** to send a bot to a **Microsoft Teams** meeting, the request fails or the bot cannot join. The MCP request model does not include a **passcode** field, and the tool description does not state that **Teams requires a passcode**. So the agent has no way to know it must supply the meeting passcode (from the `?p=...` part of the Teams URL), and it cannot pass it through MCP. ## What did you expect? - For Teams… [Read the thread](https://github.com/Vexa-ai/vexa/issues/105) · 2026-02-04 · closed · 3 comments ### The agent-api image carries the tool manifest it advertises ## Defect (F221, found by the dogfood hop) `core/agent/control_plane/routers/health.py:22` serves `GET /.well-known/mcp-tools.json` from `Path(__file__).resolve().parents[2] / "mcp.tools.v1.json"` — two levels above `routers/`, which lands on `core/agent/mcp.tools.v1.json` in the image (`/app/mcp.tools.v1.json`, since `PYTHONPATH=/app` and the control-plane package tree is copied to `/app`). `core/agent/services/agent-api/Dockerfile` never COPYs that file. It COPYs `shared/`,… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1534) · 2026-09-03 · closed · 1 comment ### flows runs, tests and ships without the agent prompts, a private vault, or a named container ### Value this issue delivers The flows service runs, tests and ships without the agent's prompts, a private vault, or a named container on one host. Four things, each witnessable on its own: 1. A checkout without `behavior/prompts/` **collects and runs the flows suite** — today fifteen test modules fail to import, and a deployment that never dispatches an agent turn still cannot load the flow definitions describing its own meetings. 2. A checkout without `core/agent/` **runs the flows suite… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1481) · 2026-09-03 · open · 1 comment ## Most recent ### [DEV] mcp: request_meeting_bot cannot start a Zoom bot — it drops the meeting_url the bots API requires for zoom (422) **Observed on production 2026-09-06 17:33Z (v0.12.27 rc.3 packet, seq-34)**, founder witness on Zoom: two `POST /bots` from the founder's agent → meeting-api **422**, twice; the agent reported "Vexa API doesn't fully support Zoom". **Mechanism.** `core/meetings/services/mcp/src/vexa_mcp/app.py` `request_meeting_bot` (~L768–782): the handler pops `meeting_url`, parses it, sets `platform` / `native_meeting_id` / `passcode`, and re-attaches `meeting_url` **only when the parser returned one** (`if… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1630) · 2026-09-06 · closed · 0 comments ### mcp: a configured domain whose manifest cannot be fetched at boot is skipped silently — the door then serves a partial tool surface **Found** 2026-09-04 on the t27 delivery station (branch `oss/no-agents-mcp` @ `08687792f`, PR #1456), while proving the onboarding step in the queue. **What happened.** `core/meetings/services/mcp/src/vexa_mcp/discover.py` documents that a configured domain that does not answer fails the boot. The code `continue`s past an unfetchable `/.well-known/mcp-tools.json` instead. The mcp container came up before `flows-api` was healthy, discovered identity and meetings, skipped flows, and served **14… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1533) · 2026-09-03 · open · 0 comments ### A Kubernetes install of flows cannot start: the flows-api pod is given none of the doors it refuses to boot without, and binds a loopback nothing can reach ### Value this issue delivers > An operator who installs the chart with `flows.enabled=true` gets a flows API that is actually > running and actually reachable from the cluster — instead of a pod that refuses to start and a > Service that would route to nothing if it did. ### Why this matters The chart already ships flows: a Secret, a worker Deployment, a mailbox Deployment, a `flows-api` Deployment and a Service for it. Two of the three pods are wired; the third is not, and it is the one… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1484) · 2026-09-03 · open · 0 comments ### Flows only runs on the dogfood box: no compose service, so a deployment that carries the domain still serves none of its tools ### Value this issue delivers > Flows runs as its own service in any deployment, without the dogfood host scripts — so an > operator who brings up the stack gets the flows tools on their MCP surface, and a deployment > that carries no agent domain and no terminal still boots. ### Why this matters Flows is a domain of the product, and it is the only one you cannot deploy. Its three processes run as HOST processes out of `deploy/dogfood/rig/flows-up.sh` on the rig box's loopback, and the… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1475) · 2026-09-03 · open · 1 comment ### Your own Claude Code can list and cancel the meeting joins you scheduled — and only yours ### Value this issue delivers > A person's own Claude Code can list and cancel the meeting joins **they** scheduled, through the Vexa MCP endpoint, using their own Vexa credential — and can see nobody else's. ### Why this matters The product configuration we are shipping is "connect your Claude Code to meetings": the person's agent talks to the Vexa endpoint with the person's own credential, and nothing else. Two of the four reaction-engine tools on that endpoint — `reactions_list` (what am… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1468) · 2026-09-03 · open · 1 comment ### Meetings in your own Claude Code: connect a client, and the bot joins your calendar invites — with no cloud agent ### Value this issue delivers > A person connects their own Claude Code to a Vexa deployment and gets their meetings there: the bot joins from their calendar invite, the transcript is waiting when the call ends, and one question — what is waiting — answers afterwards. Nothing of theirs leaves their machine: no cloud agent, no hosted workspace, no web client. Stated as the separate values a reader can witness (D5b): > **V1.** Connect an MCP client to a deployment and list your meetings and… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1465) · 2026-09-03 · open · 0 comments ### mcp: the front door answers healthy with its ticket sink unset and no domains reachable — an operator cannot tell it is half-configured ### Value this issue delivers > An operator can see whether the MCP front door is actually configured — and a deployment that is > missing something it needs refuses to start, instead of coming up green and quietly doing less. ### Why this matters The MCP service is the surface a person's own agent connects to. It is the front door of the product, and it is the one service in the stack with no deployment-config declaration: eleven environment keys, no `config.v1.json`, no boot preflight, and… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1463) · 2026-09-03 · open · 0 comments ### the /mcp surface is completely unmeasured — the gateway forwards it verbatim, so we cannot say which tools agents call ### Value this issue delivers > "How do agents actually use Vexa?" becomes a number: which MCP tools get called, by which > account, how often, with what latency and what error rate — where today the `/mcp` traffic passes > through the gateway completely unobserved. ### The substrate today `/mcp` and `/mcp/{path}` are forwarded verbatim by the gateway (`core/gateway/services/gateway/src/gateway/app.py`) to the MCP service. The forward is deliberate and correct — it is what lets a sessioned… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1113) · 2026-08-10 · open · 0 comments ### transcripts are not searchable: no search route, no MCP search tool — every read requires already knowing the meeting id ### Value this issue delivers > An agent (or a person) asks "what was said about X?" across an account's meeting history and > gets back ranked, dated, attributed transcript segments — over one REST route and one MCP tool — > where today the only way to find anything is to already know the meeting id. ### The substrate today Measured against `https://api.cloud.vexa.ai` on 2026-08-10 with a real account key, read-only: | Probe | Result | |---|---| | `GET /transcripts/search` | `404 Not… [Read the thread](https://github.com/Vexa-ai/vexa/issues/1112) · 2026-08-10 · open · 0 comments The remaining reports are on [the project's issue tracker](https://github.com/Vexa-ai/vexa/issues).