Jitsu MCP server: an agent that sets up and debugs your event pipeline
The Jitsu MCP server lets an AI agent run your event pipeline through 26 tools: it creates destinations and connections, reads Live Events, tests a function against a sample event and ships the fix. It works with Claude Code, Claude Desktop, Cursor and VS Code, and every change it makes is recorded in the audit log.
There is one endpoint:
https://use.jitsu.com/mcp
On an on-premise install, the server is at /mcp on your own console host.
Connect a client
In Claude Code it is one command:
claude mcp add --transport http jitsu https://use.jitsu.com/mcp
Cursor reads it from ~/.cursor/mcp.json:
{
"mcpServers": {
"jitsu": {
"url": "https://use.jitsu.com/mcp"
}
}
}
Claude Desktop takes the same URL under Settings, Connectors, Add custom connector. VS Code takes it in .vscode/mcp.json. The MCP docs have the configuration for each client.
The first time the agent calls a Jitsu tool, a browser tab opens and asks you to approve the connection. No API key is pasted into a config file. The connection appears under API Keys in your account, and revoking it there disconnects the client immediately.
What the 26 tools do
| Group | Tools | What the agent does with them |
|---|---|---|
| Configuration | list_workspaces, list_resources, get_resource, get_resource_schema, create_resource, update_resource, delete_resource | Reads the JSON Schema for a destination, stream, function or connection, then creates or changes it |
| Live Events and testing | list_event_sources, query_events, test_connection, run_function, run_profile_builder | Reads incoming events, function logs, warehouse write statuses and the dead-letter queue. Tests credentials. Runs a function on a sample event with nothing saved |
| Connectors and syncs | get_connector_spec, check_source_credentials, get_source_check_result, discover_streams, run_sync, cancel_sync, list_sync_tasks, get_sync_logs, get_sync_state, reset_sync_state | Checks a source's credentials, lists the streams it can sync, starts and cancels runs, reads their logs |
| Statistics | get_event_stat, get_sync_stat, get_profile_builder_stats | Counts events per period, connection, destination and status |
| Audit log | get_audit_log | Reads what changed, who changed it, and whether it came from the UI, the API, the CLI or an agent |
What that adds up to
An agent with configuration tools alone can create a connection and has no way to tell whether it works. The Jitsu server also gives it the two things an engineer uses to debug: Live Events and a way to run a function.
So one prompt covers the whole loop:
Route my web stream into ClickHouse, but only purchase and signup events. Send a test event, check Live Events, and if anything errors, find the function in the path and fix it.
The agent calls get_resource_schema and create_resource to build the connection, query_events to read what arrived, get_resource to open the function that threw, run_function to prove the fix on a sample event, and update_resource to ship it.
Other prompts that map to the tools:
| Prompt | Tools it uses |
|---|---|
| "Is my new storefront sending events?" | list_event_sources, query_events |
| "Why did yesterday's checkouts not reach the warehouse?" | query_events filtered to errors, get_event_stat |
| "Did the Stripe sync finish, and what did it log?" | list_sync_tasks, get_sync_logs |
| "What did agents change in this workspace last week?" | get_audit_log with origin mcp |
Controls on what an agent can do
Every tool carries the standard MCP annotations, so a client can run read-only tools without asking and stop for confirmation on the ones that change something. The destructive ones are update_resource, delete_resource and reset_sync_state.
The server enforces the same rule on its side: while a deployment is in maintenance mode, tools that are not read-only are rejected.
An agent acts with the access of the person who connected it. Every configuration change made through the MCP server is written to the workspace audit log with an MCP origin, so a change made by an agent is told apart from one made in the UI or by a script.
In CI and other headless jobs
A browser approval cannot run in CI. There the agent authenticates with a personal API key, the same key the Management API and the jitsu-cli use:
claude mcp add --transport http jitsu https://use.jitsu.com/mcp \
--header "Authorization: Bearer $JITSU_API_KEY"
Keys are created on the user settings page, carry a name, can be given an expiration date, and are revoked from the same page.
Questions people ask
What is the Jitsu MCP server? It is a Model Context Protocol server at https://use.jitsu.com/mcp that gives an AI agent 26 tools to configure a Jitsu pipeline, read Live Events, run connector syncs, read statistics and read the audit log.
Which clients work with the Jitsu MCP server? Claude Code, Claude Desktop, Cursor and VS Code with GitHub Copilot are documented. The endpoint is the same in each.
Does the Jitsu MCP server work on an on-premise install? Yes. The server is at /mcp on your own console host.
How does an agent authenticate? Interactive clients use OAuth 2.1 with a browser approval. CI and other headless jobs send a personal API key in an Authorization header.
Is there a record of what an agent changed? Yes. Every configuration change made through the MCP server is written to the workspace audit log with an MCP origin.
Does the Jitsu MCP server cost extra? No. The MCP server is part of the Jitsu console, on Jitsu Cloud and on-premise.
Get started with Jitsu
Create a free Jitsu Cloud workspace, run the claude mcp add command above, and ask the agent to list your workspaces. The MCP docs list every tool, and five prompts to run a pipeline from Claude Code, by Soham Mehta, walks through a full session.