MCP Server

Overview

The Veltrix MCP server lets AI assistants — Claude Desktop, Claude Code, or any client that speaks the Model Context Protocol — connect to your Veltrix tenant natively. The assistant sees a curated set of tools for drafting, validating, and submitting security-configuration changes, checking pipeline and drift status, and deploying already-approved changes.

It is a thin adapter over the same REST API the portal uses: every tool call carries your API key, so tenant isolation, role-based permissions, tier quotas, and rate limits are enforced by the platform — not by the MCP layer. Veltrix ships the guardrails, not the model; the MCP server includes no LLM.

Two transports are supported: stdio for local assistants (the key comes from the client's environment config) and Streamable HTTP for remote or multi-tenant use (each request carries its own key, so one server process safely serves many tenants).

Security Model

• No approvals, credentials, or account management. There are deliberately no approve/reject tools, no credential tools, and no user- or API-key-management tools. Approval decisions always happen in the portal, by named humans.
• Role-bound keys, fail closed. Every session authenticates with a vltx_ API key bound to an RBAC role; a key without a role is rejected. Scope the role to what the assistant should do — a read-only key can't draft anything.
• Attributed actions. Changes made through MCP are attributed in the audit trail to your tenant's non-loginable "API Integration" identity, so AI-made changes are always distinguishable from human ones.
• Pipeline still rules. Deploying an unapproved canvas fails; quotas and trial gates apply; drift detection watches the result. The MCP server cannot bypass any pipeline stage.
• Paid plans only. MCP access requires a paid plan; tenants on the free tier are told to upgrade before connecting AI tooling.

Setup

1. Create an API key in the portal (Settings → API Keys) and bind it to a role with the permissions you want the assistant to have.

2a. Hosted (recommended). The MCP server already runs as a managed service on the hosted platform at https://app.veltrixsecops.com/mcp — nothing to run yourself. Point your client at it over Streamable HTTP with the key per request. Claude Code:

claude mcp add --transport http veltrix https://app.veltrixsecops.com/mcp \
  --header "Authorization: Bearer vltx_..."

2b. Local / self-host. The server is published on npm as @veltrixsecops/mcp-server (source in the veltrix-apps repo, bin veltrix-mcp). Run it over stdio for a desktop client. Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "veltrix": {
      "command": "npx",
      "args": ["-y", "@veltrixsecops/mcp-server"],
      "env": {
        "VELTRIX_API_URL": "https://app.veltrixsecops.com",
        "VELTRIX_API_KEY": "vltx_..."
      }
    }
  }
}

Or run it yourself in Streamable HTTP mode (binds 127.0.0.1 by default; expose deliberately with --host):

VELTRIX_API_URL=https://app.veltrixsecops.com npx -y @veltrixsecops/mcp-server --http --port 5100

# every POST /mcp request carries: Authorization: Bearer vltx_...  (or x-api-key: vltx_...)

Tool Reference

Typical Workflow

1. The assistant calls veltrix_whoami to confirm the tenant and see what its key permits.
2. It drafts a change with veltrix_create_canvas and runs veltrix_validate_canvas until the app's validator passes.
3. It submits the draft to named human approvers with veltrix_submit_canvas_for_approval.
4. Humans review the visual diff and approve — in the portal, never over MCP.
5. Once approved, the assistant (or a human) deploys with veltrix_deploy_canvas and tracks it with veltrix_get_deployment; drift detection watches the result from then on.