Striim MCP Server

The Striim MCP Server lets external AI agents and assistants operate Striim through natural language using the Model Context Protocol (MCP), an open standard for connecting AI applications to tools and data. Any MCP-compatible client — such as Claude Code, Claude Desktop, Cursor, or your own agents — can connect to Striim and manage applications, run and validate TQL, inspect live streaming data, monitor components, and administer users and roles, all governed by Striim's existing security model.

The MCP server is embedded in the Striim server itself. It is not a separate process or installation: it is served from the /mcp endpoint of the same web container that serves the Striim web UI and REST API, and it reuses Striim's authentication, authorization, TLS, logging, and audit infrastructure. If your Striim server is running, its MCP endpoint is running with it. There is no standalone or separately installable version of the MCP server.

The Striim MCP Server complements Striim's other AI capabilities: the AI Agents that run as components inside your application flows, and the Striim AI assistant built into the Striim UI. The MCP server is the interface for AI tools that run outside Striim.

Lifecycle

Because the MCP server is embedded in the Striim server, it has no independent lifecycle:

Setup: no separate installation is required. The MCP server ships as part of the Striim server.
Start and stop: the MCP endpoint starts and stops with the Striim server. There is no separate MCP process to manage.
Upgrades and patches: the MCP server is upgraded when you upgrade Striim. There is no separately versioned MCP component, no MCP-specific state, and no MCP-specific migration steps.

The MCP endpoint is available by default: no MCP-specific configuration is required before clients can connect. If your security policy requires the endpoint to be off, an administrator can disable it by setting MCPEnabled=false in startUp.properties and restarting the Striim server (see Configuration).

Note

Session tokens are invalidated when the Striim server restarts. After a restart or upgrade, MCP clients must authenticate again to obtain a new token.

Connecting an MCP client

The MCP server uses the same session authentication as the Striim web UI and REST API. Connecting a client has two parts: generate an MCP token, then register the Striim MCP server with your client so that it passes the token with every request.

Generating an MCP token

An MCP token authenticates your MCP client to Striim as your user, with exactly the permissions your Striim user has. Generate the token in the Striim web UI, or request one from the authentication REST endpoint.

Using the Striim web UI

In the navigation pane, select Striim AI > MCP. The Striim Model Context Protocol (MCP) page displays the server endpoint for your Striim server. Copy the endpoint, as you need it when you register the server with your client.
Under Generate MCP Token, enter your Striim password and click Generate token. The token is scoped to MCP access only and does not affect your current browser session.
Under Your MCP Token, copy the token. You can also reveal the token to read it. Treat the token like a password: anyone who has it can access the MCP server as you.

Using the REST API

Obtain a session token by authenticating with your Striim credentials:

TOKEN=$(curl -sS -X POST https://<striim-host>:9081/security/authenticate \
      -d "username=<user>&password=<password>" | jq -r .token)

Note

The /mcp endpoint is also served on Striim's HTTP port (9080 by default). Use HTTPS so that your credentials and session token are not transmitted in clear text. Treat the token like a password.

Registering the Striim MCP server with your client

Register the server with your MCP client, passing the token in the Authorization header of every request. The following examples show three common clients.

Register the Striim MCP server with your client, passing the token in the Authorization header of every request.
Using the Claude Code command line:
```
claude mcp add --transport http striim http://localhost:9080/mcp 
  --header "Authorization: STRIIM-TOKEN <token>"
```
Using Claude Desktop, add the server to claude_desktop_config.json:
```
"mcpServers": {
  "striim": {
    "type": "http",
    "url": "https://<striim-host>:9081/mcp",
    "headers": {
      "Authorization": "STRIIM-TOKEN <your-token>"
    }
  }
}
```
Using Cursor, choose Settings > MCP > Add Server, set the type to http, enter the URL as above, and add the header Authorization: STRIIM-TOKEN <your-token>.
Verify the connection. For example, in Claude Code, run the /mcp command and confirm that striim appears as connected, then ask the agent to list your running Striim applications.
If the Striim server restarts or the session is logged out, generate a new token and update it in your client configuration.

The connection uses JSON-RPC 2.0 over HTTPS (the MCP Streamable HTTP transport) to the single /mcp endpoint. Any client that implements the Model Context Protocol can connect the same way.

Tool reference

In MCP, a tool is a discrete, named operation an AI client can invoke on the user's behalf. The Striim MCP Server exposes Striim's functionality as MCP tools, organized into the following categories. You do not call tools directly: you make requests in natural language, and the AI agent selects and calls the appropriate tools. The example in each category shows a typical request and the tools the agent uses to carry it out.

The tools you can see and call depend on your permissions: the server filters the tool list so each caller sees only the tools their Striim user is authorized to run. To see your available tools, connect a client and request the tool list.

No dedicated destructive tools: the MCP server does not expose tools whose purpose is to delete or tear down resources — there is no tool to drop or undeploy an application, delete a user or role, or revoke a permission. However, the striim_execute_tql tool executes arbitrary mutating TQL, including DROP, UNDEPLOY, and STOP, subject to the authenticated user's Striim permissions. To prevent an agent from tearing down or altering objects, scope its Striim user's roles and namespace permissions accordingly (see Security and governance).

Health and connectivity

Check server liveness and component health.

Tool	Description
`striim_healthz`	Quick liveness check. Returns an OK status when the Striim server is up and responding.
`striim_health_detail`	Detailed health for Striim subsystems, including servers, applications, and queues.

Example:

"Is my Striim cluster healthy?"

The agent calls striim_healthz to confirm the server is up, then striim_health_detail to check each subsystem, and summarizes anything that is degraded.

Application lifecycle and inspection

List applications, get application status and metadata (including crash reasons), create applications, deploy and start applications, inspect all pipeline components inside an application, and read checkpoints.

Tool	Description
`striim_list_apps`	Lists all applications visible to the user with their current state (CREATED, DEPLOYED, RUNNING, and so on).
`striim_get_app`	Returns the full TQL definition of an application.
`striim_app_status_summary`	Returns an application's runtime status, including lag, event rates, error counts, the last checkpoint, and crash reasons when the application has crashed.
`striim_describe_app`	Lists all components in an application's pipeline, with topology warnings for streams that are produced but not consumed (or the reverse).
`striim_get_app_checkpoint`	Returns the application's last committed checkpoint offset, which is useful for recovery planning.
`striim_create_app`	Creates an application, either empty or from a template ID. When a template is used, required template parameters are validated up front; missing parameters return an error listing them.
`striim_deploy_app`	Deploys a CREATED application to a deployment group.
`striim_start_app`	Starts a DEPLOYED application.

Example:

"List my Striim applications and tell me which ones are not running."

The agent calls striim_list_apps to list the applications visible to your user with their statuses, and uses striim_app_status_summary to summarize any that are stopped or crashed, including crash reasons from the application metadata.

Monitoring and lineage

Retrieve monitoring reports for applications and components, and read Oracle and file source/target lineage.

Tool	Description
`striim_get_monitoring_report`	Returns throughput and latency metrics for an application or an individual component.
`striim_get_oracle_lineage`	Returns data lineage for Oracle CDC sources.
`striim_get_file_lineage`	Returns data lineage for file-based sources.

Example:

"My OracleToKafka application crashed — find out why."

The agent reads the application status and crash exceptions with striim_app_status_summary, pulls the recent monitoring report with striim_get_monitoring_report, and reports the root cause.

TQL queries and files

Run read-only metadata commands, and list TQL files stored on the server.

Tool	Description
`striim_tql_query`	Runs read-only TQL metadata commands: LIST, SHOW, DESCRIBE, and USE. SELECT is not permitted through this tool; use `striim_adhoc_query` instead.
`striim_list_tql_files`	Lists the `.tql` files stored on the server.

Example:

"What CQs are defined in the analytics namespace, and what does OrderEnrichCQ do?"

The agent runs LIST and DESCRIBE commands through striim_tql_query and explains the CQ's definition in plain language.

TQL knowledge and application development

Discover available adapters and their property schemas, retrieve TQL grammar guidance per statement type, check TQL syntax without executing, and execute TQL to create applications and components. These tools guide AI agents through a structured workflow for building Striim applications (see How agents build applications).

Tool	Description
`striim_list_adapters`	Lists all registered adapters, filterable by category: source, target, connection profile, parser, or formatter.
`striim_get_adapter_schema`	Returns the required and optional properties for a named adapter (for example, KafkaReader or OracleWriter).
`striim_get_grammar_context`	Returns reserved words, syntax rules, and common pitfalls for a TQL statement type (for example, CREATE SOURCE or CREATE CQ). Multiple statement types can be retrieved in a single call.
`striim_compile_tql`	Parses and semantically validates TQL without executing it, returning any error with its line and column, plus advisory topology warnings. Use this as a quality gate before `striim_execute_tql`.
`striim_execute_tql`	Executes arbitrary mutating TQL, such as CREATE APPLICATION ... END APPLICATION, DEPLOY, START, STOP, ALTER, UNDEPLOY, and DROP, subject to the authenticated user's Striim permissions. Large TQL blocks are automatically split into safe batches.

Example:

"Create a Striim application that reads from my Kafka topic orders and writes to the OrderEvents stream."

The agent checks for an existing Kafka connection profile (creating one if needed), verifies the adapter and its required properties with striim_get_adapter_schema, retrieves the TQL grammar guidance with striim_get_grammar_context, writes the TQL and syntax-checks it with striim_compile_tql, executes it with striim_execute_tql, and then inspects the resulting application to confirm all components were created.

Adhoc queries (live stream inspection)

Run SELECT queries against live streams and WActionStores in a bounded session: start a query, fetch results with a safe, repeatable cursor, and stop the session. See Limitations for session limits.

Tool	Description
`striim_adhoc_query`	Runs a SELECT against a live stream or WActionStore. With LIMIT N, runs as a one-shot query that blocks until N rows arrive or the wait time (`wait_ms`, maximum 30,000 ms) expires. Without LIMIT, starts a streaming session and returns a query ID for use with `striim_adhoc_fetch`.
`striim_adhoc_fetch`	Drains buffered rows from a streaming adhoc session identified by its query ID.
`striim_adhoc_stop`	Stops a streaming session and releases its resources. This tool is idempotent.

Example:

"Show me 10 events from the OrderEvents stream."

The agent runs striim_adhoc_query with LIMIT 10 as a bounded one-shot query against the live stream and returns the rows. For open-ended monitoring, the agent instead starts a streaming session, drains rows with striim_adhoc_fetch, and releases the session with striim_adhoc_stop.

Connection profiles

List connection profiles and create or replace profiles for adapters that require them.

Tool	Description
`striim_list_connection_profiles`	Lists all connection profiles in the cluster.
`striim_create_connection_profile`	Creates or replaces a connection profile. The profile name, adapter type, and property key names are validated against an identifier allowlist before any TQL is generated.

Example:

"Do we already have a connection profile for the orders Kafka cluster? If not, set one up."

The agent checks with striim_list_connection_profiles and, if none matches, gathers the required properties from the adapter schema and creates the profile with striim_create_connection_profile. Note that credential values in tool responses are masked by secrets redaction (see Data privacy).

Users, roles, and permissions

List, create, update, and activate or deactivate users; list and create roles; grant roles and object permissions. Revoking permissions is not exposed.

Tool	Description
`striim_list_users`	Lists all users.
`striim_get_user`	Returns details for a specific user.
`striim_create_user`	Creates a user.
`striim_update_user`	Updates a user's email address or other attributes.
`striim_set_user_active`	Enables or disables a user account.
`striim_list_roles`	Lists all roles.
`striim_get_role`	Returns details for a specific role.
`striim_create_role`	Creates a role.
`striim_grant_roles_to_user`	Assigns one or more roles to a user.
`striim_grant_roles_to_role`	Nests a role inside another role.
`striim_grant_object_perms_to_user`	Grants permissions on a Striim object (application, stream, and so on) to a user.
`striim_grant_object_perms_to_role`	Grants permissions on a Striim object to a role.

Example:

"Create a user for our monitoring agent that can read the analytics namespace but change nothing."

The agent creates the user with striim_create_user and grants read-only permissions on the namespace with striim_grant_object_perms_to_user. This is also the recommended way to provision dedicated, minimally privileged users for AI agents (see Security and governance).

System alerts

List, read, and update system alerts.

Tool	Description
`striim_list_alerts`	Lists all system alerts.
`striim_get_alert`	Returns details for a specific alert.
`striim_update_alert`	Modifies an alert's thresholds or notification settings.

Example:

"Which alerts fired this week, and raise the memory alert threshold to 90 percent."

The agent reviews alerts with striim_list_alerts and striim_get_alert, then adjusts the threshold with striim_update_alert.

Metering and billing

Read usage summaries, consumption, metered entities, rate plans, and credits. Administrators can create billing cycles. These tools apply to Striim Cloud.

Tool	Description
`striim_metering_summary`	Returns a high-level metering summary.
`striim_list_metered_entities`	Lists metered objects: adapters, applications, components, and data entities.
`striim_get_usage`	Returns a detailed usage breakdown for the current or a historical scope.
`striim_get_consumption`	Returns consumption data by entity and time range.
`striim_get_credits`	Returns remaining cloud credits.
`striim_get_rate_plan`	Returns the current pricing and rate plan.
`striim_list_billing_cycles`	Returns the billing period history.

Example:

"How much of our credit balance did the CDC applications consume this month?"

The agent combines striim_get_credits with striim_get_consumption filtered by entity and time range, and summarizes the result.

Introspection

Identify the authenticated user and their roles and permissions, and read cluster information.

Tool	Description
`striim_whoami`	Returns the username and roles of the user the token authenticates as.
`striim_cluster_info`	Returns the cluster name, node count, node roles, and topology.

Example:

"Which Striim user are you connected as, and what can you do?"

The agent calls striim_whoami and reports the username and roles behind its token — a useful first check when a tool call unexpectedly returns AUTH_DENIED.

How agents build applications

When an AI agent connects, the MCP server provides it with a structured workflow for building Striim applications: verify that required connection profiles and adapters exist, retrieve the TQL grammar rules for the statement types it will use, design the pipeline, check the TQL syntax, execute the TQL, and then deploy, start, and verify the application. This guidance steers agents to validate their work before and after each step, using the same components and checks that Striim applies to TQL from any other source.

Configuration

The MCP server requires no configuration to use. Operators can tune the following settings in startUp.properties. Changes take effect when the Striim server is restarted.

Setting	Description	Default
`MCPEnabled`	Enables or disables the embedded MCP endpoint. Set to `false` to disable the endpoint entirely if your security policy requires it.	true
`MCPAllowedOrigins`	Comma-separated allowlist of browser origins permitted to call the MCP endpoint. Loopback origins are always trusted, so a same-host browser client works without configuration; set this only to allow a remote browser-based client (for example, `MCPAllowedOrigins=https://striim.example.com`), or `*` to allow all origins (not recommended in production). Non-browser clients are unaffected.	Loopback only
`MCPExecutorThreads`	Size of the dedicated worker pool that executes MCP tool calls. Each concurrent tool call occupies one worker for its duration.	16
`MCPQueueDepth`	Maximum number of tool calls that may wait in the queue when all workers are busy. Requests beyond this limit are rejected immediately with `RATE_LIMITED`.	32
`MCPReadBudgetPerMin`	Per-user, per-tool rate limit for read tools, in calls per minute.	60
`MCPWriteBudgetPerMin`	Per-user, per-tool rate limit for write tools, in calls per minute.	20
`MCPAdhocZmqStartupDelayMs`	Milliseconds to wait after starting an adhoc SELECT before collecting rows, allowing the internal subscriber to initialize. Events emitted before this delay may be missed; increase this value on slow or heavily loaded nodes if adhoc queries return no rows.	300
`MCPAdhocZmqShutdownGraceMs`	Milliseconds to wait after stopping an adhoc SELECT before unsubscribing, allowing in-flight events to drain into the row buffer.	300
`MCPLoopbackTimeoutSecs`	Timeout in seconds for a tool's internal call to Striim's REST API. Increase on slow or cold nodes or large clusters.	150

Note

Rate limits are enforced per node. On a multi-node cluster, the effective limit for a user and tool is the per-node budget multiplied by the number of nodes.

Sizing

No AI model runs on the Striim server. The language model belongs to the connected MCP client (for example, the model behind Claude or Cursor), and its compute is provisioned entirely on the client side. The Striim server only executes tool calls — the same kinds of REST and metadata operations the Striim UI performs.

MCP load is deliberately isolated from Striim's data plane: tool calls run on a dedicated, bounded worker pool (16 workers and a queue depth of 32 by default), requests are capped at 256 KB, and every call has a per-call timeout (10 seconds for read tools, 60 seconds for write tools). Under saturation the server sheds MCP load with rate-limit responses rather than competing with your streaming applications for resources.

Because of these bounds, the MCP server's overhead is negligible: no additional cores or memory need to be provisioned for it. MCP usage does not count toward Striim metering or licensing.

Security and governance

The MCP server applies Striim's existing security model to AI agents. An agent has exactly the capabilities of the Striim user it authenticates as, and nothing more:

Authentication: the same session tokens used by the Striim UI and REST API. There is no separate MCP credential type to manage. Tokens are invalidated on server restart and are never written to logs. Treat tokens like passwords.
Authorization: the tool list is filtered to what the authenticated user may run, and every tool call is re-checked against the user's permissions. Namespace-level access controls are enforced on every operation, exactly as they are for the UI.
No dedicated destructive tools: no tools are exposed whose purpose is to delete or undeploy resources or revoke permissions. However, striim_execute_tql executes arbitrary mutating TQL, including DROP and UNDEPLOY, governed entirely by the authenticated user's Striim permissions — so permission scoping, not the tool surface, is what prevents destructive operations.
Rate limiting and timeouts: per-user, per-tool budgets with separate read and write limits contain the impact of a misbehaving or runaway agent. Every call also has a per-call timeout: 10 seconds for read tools, 60 seconds for write tools, and up to 30 seconds for one-shot adhoc queries. Timed-out calls are cancelled server-side.
Audit trail: every tool call is recorded in Striim's audit log with the user, tool, outcome, duration, and a correlation ID. Agent activity is audited under the same subsystem as all other Striim user activity, so existing audit review processes cover it. In the server log, these entries appear under the mcp.audit logger.
Browser origin validation: requests carrying a browser Origin header are checked against the configured allowlist, preventing malicious web pages from driving the MCP endpoint from an operator's browser. Non-browser clients are not affected.

For governance purposes, the recommended practice is to create dedicated Striim users for AI agents with the minimum roles and namespace permissions the agent's tasks require, so that agent capabilities, rate budgets, and audit records are scoped and attributable per agent.

Data privacy

The Striim MCP Server does not send data anywhere on its own. It only responds to requests from connected MCP clients, and the Striim server does not communicate with any AI model or external service.

However, any data a tool returns is delivered to the connected MCP client and from there to whatever AI model the client uses. This includes metadata (application names, component definitions, statuses, user and role information) and, if the agent uses the adhoc query tools, the contents of live streaming events. Once returned to the client, that data is subject to the client's and its AI provider's data handling terms, not Striim's.

Two protections apply on the Striim side:

Secrets redaction: every tool response is scanned server-side before it leaves Striim. Credential values — including passwords, API keys, bearer tokens, JWTs, cloud provider keys, and other high-entropy secrets — are masked, as are the values of fields with names such as password, secret, api_key, token, private_key, and passphrase. Error messages are redacted the same way. Redaction is best-effort, based on pattern and field-name matching, and covers secrets only — it does not redact the content of your streaming data.
Permission scoping: an agent can only retrieve data its Striim user is authorized to read. Restricting the agent's user to specific namespaces and roles restricts what data can leave Striim through the MCP interface.

The MCP server has no PII redaction and no server-side data-residency controls: if an adhoc query runs against a stream that carries personal or otherwise sensitive data, that data is delivered to the client as-is.

If your data governance policies restrict where streaming data may be processed, control which AI clients and models your organization connects, and scope agent users so that sensitive streams are not readable by them.

Troubleshooting

MCP tool calls return structured error codes (with the corresponding JSON-RPC numeric codes):

Code	JSON-RPC code	Meaning	Resolution
`AUTH_DENIED`	`-32001`	The token is invalid or expired, or the user lacks permission for the tool.	Generate a new token (required after every Striim server restart) and update it in the client configuration, or grant the user the required role or permission. If only write tools fail, the user lacks write permissions.
`NOT_FOUND`	`-32002`	The target resource does not exist.	Verify the fully qualified name, including the namespace prefix.
`CONFLICT`	`-32003`	The operation conflicts with the resource's current state (for example, deploying an application that is already deployed).	Check the resource's current status before retrying.
`INVALID_ARG`	`-32602`	Argument validation failed.	Check the tool's input schema; object names generally require the `namespace.name` format.
`RATE_LIMITED`	`-32004`	The per-user rate budget for the tool is exhausted, or the server is saturated.	Wait for the interval indicated by the Retry-After value, or raise the relevant budget setting.
`TIMEOUT`	`-32005`	The tool call exceeded its per-call deadline.	Retry; for long-running TQL, break the work into smaller statements. For adhoc queries on low-volume streams, increase the `wait_ms` parameter (maximum 30,000 ms). If internal REST calls time out on slow or cold nodes, increase `MCPLoopbackTimeoutSecs`.
`UNAVAILABLE`	`-32006`	The server is shutting down or the MCP feature is disabled.	Retry after the server is available, or confirm the MCP server is enabled (`MCPEnabled` in `startUp.properties`).
`INTERNAL`	`-32603`	A server-side error occurred.	Note the correlation ID from the error response and contact support.

Every error response includes a correlation ID. Administrators can find the corresponding entry in the Striim server log by searching for corrId=<value>, and can review all MCP activity under the mcp.audit logger's entries (for example, grep 'mcp.audit' striim.log). To route audit entries to a separate file, add an appender for mcp.audit in log4j.server.properties.

If an adhoc query returns no rows against a running application, the internal subscriber may not have initialized before events arrived: increase MCPAdhocZmqStartupDelayMs (see Configuration). Also verify that the application is in the RUNNING state.

Limitations

Adhoc queries are limited to 3 concurrent streaming sessions per user per transport, with a maximum session duration of 5 minutes and an idle timeout of 60 seconds. Each fetch returns at most 10,000 rows, and each session's buffer retains up to 50,000 rows (by default, the oldest rows are dropped on overflow; a blocking overflow policy can be selected per query).
Requests are capped at 256 KB. Large TQL application definitions are automatically executed in batches.
Adhoc SELECT on a stream is a live subscription: it returns events arriving while the session is active, not historical events. There is no static sample or historical replay.
Rate limits are enforced per node, not cluster-wide.
Session tokens cannot be rotated or persisted independently: token lifetime is tied to the Striim session, and tokens are invalidated when the server restarts. For Striim Cloud, there is no OAuth bridge; authenticate with a Striim username and password.
The only supported transport is MCP Streamable HTTP on the /mcp endpoint. WebSocket transport is not supported.
Stream webhooks and SAML SSO administration are not available through MCP tools. Applications can be created from templates with striim_create_app, but the interactive application template wizards of the web UI are not exposed.

Striim MCP Server

Lifecycle

Note

Connecting an MCP client

Generating an MCP token

Note

Registering the Striim MCP server with your client

Tool reference

Health and connectivity

Application lifecycle and inspection

Monitoring and lineage

TQL queries and files

TQL knowledge and application development

Adhoc queries (live stream inspection)

Connection profiles

Users, roles, and permissions

System alerts

Metering and billing

Introspection

How agents build applications

Configuration

Note

Sizing

Security and governance

Data privacy

Troubleshooting

Limitations

Search results