Connect to Vocion over MCP: your agents' tools, from any client

Until now, Vocion's MCP server and Vocion's agents held two different toolboxes. The MCP surface was the authoring and admin plane — write a skill, start a mission, approve a draft — while the tools agents actually work with (knowledge search, the typed CRM reads, the connector pulls) lived only inside the agent runtime. If you wanted the data, you asked an agent. v2.16.0 merges the two: the domain tool registry is now served over MCP, so any MCP client — Claude Code, Claude Desktop, Cursor, Zed — can call the same tools your agents run on, under the same gates.

What's new

• The agent toolbelt, bridged. search_knowledge, lookup_objects, the typed CRM reads, freshen_source, run_operation, learnings, briefings, run history — one registry, now a fourth consumer. Add a tool to the registry and every provider gets it, MCP included.

• Tools run as an agent, and the gates come with them. Every bridged call rebuilds the exact runtime context an agent run would use — its connected sources, its grants, its tool exclusions. The default agent is your workspace lead (or VOCION_MCP_AGENT_SLUG); pass agent_slug on any call to run as another agent, re-resolved and re-gated per call. An agent without a HubSpot source cannot reach get_hubspot_deals, over MCP or anywhere else.

• Cache-aware live pulls. Two new tools fetch specific documents on demand, as read-through caches over the synced mirror:

  Tool	Cache rule
  get_zoom_transcript	Transcripts are immutable — a synced transcript answers with zero API calls; a miss fetches live from Zoom and upserts it into the index
  get_gmail_thread	Threads grow — a copy fetched within the TTL (default 15 min) answers from the mirror; past it, the thread re-fetches and upserts

  Both report provenance: source: "cache" or "live", plus the upsert status. What a pull fetches, search sees afterward.

• Writes stay reviewed. propose_action over MCP proposes a connector write (gmail.send, hubspot.update) under an agent principal at working autonomy — the proposal lands PENDING in the review queue for a human, no matter whose Bearer token is calling. The token's own permissions never widen what a tool call can do to the outside world.

• Token issuance is a command now. vcn_live_… Bearer tokens for the HTTP transport used to be a manual database path. Now: npm run tokens:issue -- --org <slug> --name "my integration", with tokens:list and tokens:revoke beside it. The plaintext prints once; only the hash is stored.

Connecting

Hosted or self-hosted, the HTTP transport is one endpoint, multi-tenant, org-scoped by token:

npm run tokens:issue -- --org revenue --name "my laptop"

POST https://your-install/api/mcp
Authorization: Bearer vcn_live_...

Point any remote-capable MCP client at that URL with the header. For a local, single-tenant setup, the stdio transport still works: claude mcp add vocion -- npm --prefix /path/to/checkout run mcp:serve with VOCION_ORG_ID set.

Where to find it

The full tool reference, cache semantics, and extension guide live in the MCP reference. If you work in Claude Code, the companion post — Driving Vocion from Claude Code — walks the day-to-day patterns.

Get it

Pull v2.16.0, run migrations, and issue a token. Everything above ships in core — no new services, no config beyond the optional VOCION_MCP_AGENT_SLUG.