Get Started

allv Developers

Connect MCP clients and AI agents to your allv workspace.

Use allv's MCP server and developer access model with a workspace API key, a selected-user header, and the same tools, memory, and approvals already configured in the app.

Get StartedMCP Server Docs

Cursor works today with custom headers. Claude Desktop needs a different auth path for this v1 model.

Developer Access

MCP v1
Streamable HTTPAPI keySelected userRead-only memory

One endpoint, one selected workspace member.

Remote MCP clients connect to /workspaces/:workspaceId/mcp with a workspace API key and either x-allv-user-id or x-allv-user-email. Tools run in that member context, while memory resources remain read-only.

Access Modes

Choose between MCP-compatible clients and app-specific integrations.

MCP Server Mode

Best for Cursor and other MCP-compatible clients that should connect directly to workspace tools and read-only memory over Streamable HTTP.

Agent API

Best when your own product or service owns the request and response contract and needs allv behind an application-specific entrypoint.

Real Integration Patterns

Start with the actual endpoint, headers, and client setup used in production.

Node client

TypeScript
import { Client } from "@modelcontextprotocol/sdk/client/index.js";import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";const transport =  new StreamableHTTPClientTransport(    new URL("https://agent.allv.ai/api/workspaces/<workspaceId>/mcp"),    { requestInit: { headers: {      Authorization: "Bearer sk_live_...",      "x-allv-user-email": "user@example.com",    } } },  );const client = new Client({ name: "ops-client", version: "1.0.0" });await client.connect(transport);

Cursor mcp.json

JSON
{  "mcpServers": {    "allv-production": {      "url": "https://agent.allv.ai/api/workspaces/<workspaceId>/mcp",      "headers": {        "Authorization": "Bearer ${env:ALLV_API_KEY}",        "x-allv-user-email": "${env:ALLV_USER_EMAIL}"      }    }  }}

Use Cases

Developer access should extend the product, not fork the control plane.

IDE companions

Connect Cursor or another MCP-compatible client to the same workspace tools, memory, and approvals already configured in allv.

Internal tooling

Let internal dashboards, review queues, and scripts run against the real workspace context instead of a duplicate integration layer.

Approval-aware automation

Keep external access aligned with the same approval rules, run visibility, and audit trail that operators use inside the product.

How It Works

Feature flag, auth, and memory rules stay explicit.

Enable mcp_server_v1, authenticate with a workspace API key, and select the workspace member that should own tool execution. Read memory through MCP resources and mutate memory through tools such as agent.update_memory.

  • check_circleUse Authorization or x-api-key plus x-allv-user-id or x-allv-user-email.
  • check_circleMCP resources are read-only views; tools still perform writes and approval-aware actions.
  • check_circleStreamable HTTP clients should use POST to the workspace MCP endpoint.

Related features

Developer access is most useful when it stays connected to the workspace.

Connections

Reuse the same Gmail, Slack, GitHub, Notion, and provider integrations already configured in the app.

Workflows

Launch or inspect the same branching, approval-aware automations your operators use in the product.

Memory

Read durable context and keep external agent behavior aligned with team preferences and prior decisions.

Connect MCP-compatible clients.Keep one workspace control plane.

Extend allv into developer workflows without losing workspace context, approvals, memory, or visibility.

Get StartedRead MCP Docs
MCP server mode is strongest when it stays tied to the same workspace model as the app.