MCP Server

Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edit Functions.

There is a single endpoint:

https://use.jitsu.com/mcp

For interactive clients, authentication is OAuth 2.1 — you don't paste an API key. The first time a client uses the server, a browser tab opens asking you to approve the connection. Approve it once and the client gets a scoped, revocable token. The connection shows up under your account and can be revoked any time (see Managing access).

In CI and other headless environments the browser flow can't run. There you authenticate with a personal API key instead — see Automation and CI.

Connect a client

The endpoint is the same everywhere; only the configuration format differs.

claude mcp add --transport http jitsu https://use.jitsu.com/mcp

{
  "mcpServers": {
    "jitsu": {
      "url": "https://use.jitsu.com/mcp"
    }
  }
}

{
  "servers": {
    "jitsu": {
      "type": "http",
      "url": "https://use.jitsu.com/mcp"
    }
  }
}

Automation and CI

OAuth needs a browser, so it doesn't work in CI, cron jobs, or any headless setup. For those, authenticate with a personal API key — the same key the Management API uses. The key maps to your user and inherits your workspace access, so an agent running with it can do anything you can.

Generate a key on the user settings page and pass it in an Authorization header. API keys have the format {keyId}:{keySecret}; the secret is shown only once at creation. Keys can be set to never expire, which is what you want for CI.

Authorization: Bearer <api-key>

With Claude Code, add the header on the command line:

claude mcp add --transport http jitsu https://use.jitsu.com/mcp \
  --header "Authorization: Bearer $JITSU_API_KEY"

For clients configured through a file, set a static header on the server — the same shape as in Connect a client, plus a headers block. Read the key from an environment variable rather than committing it. For Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "jitsu": {
      "type": "http",
      "url": "https://use.jitsu.com/mcp",
      "headers": {
        "Authorization": "Bearer ${JITSU_API_KEY}"
      }
    }
  }
}

VS Code uses a top-level servers key instead of mcpServers; add the same headers block to the jitsu entry shown in its tab above.

Revoke a key from the same API Keys page to cut off access.

What the agent can do

The tools mirror the Management API and cover the whole surface: configuration, Live Events, connector syncs, testing and debugging, and usage statistics.

Configuration

Every configuration object follows the same list / get / create / update / delete shape, so an agent that learns one resource knows them all.

Resource type is one of destination, stream, service, function, connection, domain, custom-image, or notification. The agent typically calls get_resource_schema first to learn the exact payload, then create_resource or update_resource.

Live Events, testing and debugging

query_events exposes the same real-time stream as the Live Events view in the UI, and takes the same filters an operator would use: a single source or all of them at once, log levels (e.g. errors only), a time range, and substring search. The agent calls list_event_sources first to find the stream, connection, or destination to watch. Combined with the config tools, this lets an agent verify its own work — create a connection, send a test event, check that it landed.

Because Functions are configuration objects too, the agent can read a function's code with get_resource, try a fix against a sample event with run_function, and ship it with update_resource. So when Live Events shows a function throwing, the agent can find the bug, prove the fix, and deploy it without leaving the conversation.

Connectors and syncs

The full connector lifecycle — from checking credentials to re-running a sync from scratch:

Connector operations that talk to the actual source (get_connector_spec, discover_streams, check_source_credentials) are asynchronous: the first call starts the work and the agent polls until the result is ready. The tool descriptions spell this out, so agents handle it on their own.

Statistics

Audit log

get_audit_log reads one workspace when given its id or slug (workspace owners only), or every workspace when called without one (platform admins only). Results are paged: when a response carries nextCursor, the agent passes it back as cursor to get the next page. With origin: mcp an agent can review exactly what it — or another agent — changed before.

Tool annotations

Every tool carries the standard MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), so a client can auto-approve read-only tools and ask for confirmation only where it matters — the genuinely destructive ones are update_resource, delete_resource, and reset_sync_state. The annotations are enforced server-side too: tools that aren't read-only are rejected while the deployment is in maintenance or read-only mode.

Managing access

Each connected client holds a token issued through OAuth. To see or revoke them, open the API Keys section of your account. Revoking a key disconnects that client immediately; reconnecting re-runs the browser approval.

Every configuration change made through the MCP server lands in the workspace audit log with an MCP origin, so you can always tell what an agent changed, as opposed to a person in the UI or a script on the API. The log is also readable through MCP itself — workspace owners (and platform admins, across workspaces) can call get_audit_log to review what changed and by whom.