MCP over HTTP: one endpoint, every tenant
The agent/tool plane goes multi-tenant. A single Streamable-HTTP MCP endpoint where the org is derived from a tenant Bearer token — every tool call scoped to that org, under the same permission model as a human.
Vocion has spoken MCP since early on — but only over stdio: one org per
process, fixed by an environment variable. That's exactly right for a developer wiring Vocion into
their local Claude or Cursor. It's exactly wrong for a hosted runtime that an app, or a fleet of
agents, connects to. This release closes that gap (v1.34): MCP over HTTP, multi-tenant.
The org comes from the token
There's one endpoint:
POST https://your-install/api/mcp
Authorization: Bearer vcn_live_...
No per-org process, no shared secret. The server derives the tenant from the Bearer token — the
same vcn_live_… credential the write API uses — and scopes that
request's MCP server to the token's org. Every tool call runs under the token's authz principal, so
listing runs, searching context, or approving a draft over MCP is governed by the same permission
model and review queue as a human in the dashboard. Authentication and authorization are one path,
whether the caller is a person, an app, or an agent.
Point any remote-capable MCP client at the URL with the header and it just works — the transport is the
standard Streamable HTTP (stateless, JSON responses), built on Web Request/Response, so it runs
natively in the app's edge/runtime with no glue.
Two planes, deliberately split
Over HTTP the workspace-authoring tools (context_write / delete / apply) are off by default.
HTTP is the runtime / data / search plane — the surface a product or an agent consumes. Authoring —
which commits to a per-org git workspace — stays on stdio or CI, where that workspace actually lives.
The split keeps a remote agent from rewriting your prompts while still letting it do the work: search
the knowledge base, run a skill, read a run, route an approval.
Why now
This is the other half of the control plane. The write API gave an app a REST surface; MCP-over-HTTP gives an agent a tool surface — both multi-tenant, both Bearer-scoped, both through one authorization layer. Together they're what FirstHQ and our reference deployments consume to drive real work. The remaining piece — an OAuth sign-in flow for clients that prefer it over a pre-issued token — is next; the token path works today.