Limits and Safety
The hosted server executes pipeline configurations posted by a remote caller. Three constraints follow from that, and each surfaces as a specific, recognizable failure.
The Processor Guard
DataStream's processor catalog includes processors that execute scripts, call external services, and write state shared across a cluster. Running those on behalf of an arbitrary remote caller would turn the tester into a way to execute code and reach networks that the caller has no other access to. The server therefore refuses to run a pipeline that configures any of them.
Every other processor in the catalog is allowed. The restriction is narrow by design: it removes the processors whose side effects leave the tester, not the ones that do the normalization work you are trying to verify.
Denied Processors
| Category | Processors | Why |
|---|---|---|
| Arbitrary code execution | script | Executes arbitrary scripts |
| External AI and LLM APIs | anthropic, openai, azureai | Call a third-party model API over the network |
| Threat intelligence and reputation | alienvault, cloudflare, virustotal, ipqs | Query an external reputation API over the network |
| Other outbound lookups | dns_lookup, enrich | Resolve DNS, or run a backend dataset and lookup query |
| Notification and ticketing | slack, msteams, telegram, pagerduty, servicenow | Post to an external webhook or create records in an external system |
| Microsoft Graph and Defender | msdefender_create, msdefender_get, msdefender_update, msgraph_get, msgraph_update | Call the Microsoft Defender or Graph API over the network |
| Shared cluster state | cache_get, cache_set, cache_delete, deduplicate | Read, write, or delete state shared across the cluster |
How the Check Runs
The check walks the entire decoded configuration, not just its top-level processor list. A denied processor nested inside a foreach, an iff, a recover, or an on_failure handler is caught in exactly the same way as one at the top level — nesting is not a way around it.
It inspects mapping keys only, never values. A denied processor name appearing as a field value, a string literal, or part of your log data does not trigger anything: a hit means the processor is genuinely configured.
When several pipelines are posted as a pack, each one is checked. A denied processor anywhere in the pack stops the whole call, since the entry pipeline may reach any of them.
A configuration that cannot be parsed as YAML is also refused, on the basis that a configuration the server cannot read is a configuration it cannot certify.
What a Rejection Looks Like
The call fails before the pipeline runs. The response names every offending processor, in alphabetical order, with the reason each is denied, and closes by telling you to remove them. Nothing is executed and no partial output is returned — a rejection is never a partial run.
Testing a Pipeline That Uses One
The guard applies to the hosted MCP server specifically. To exercise a pipeline that legitimately depends on one of these processors, use a surface that runs inside your own environment:
- The Pipeline Debugger, which runs the pipeline against your own director from the web interface.
- A director running in pipeline mode, driven from your own configuration.
A practical alternative while authoring is to split the pipeline: verify the normalization logic through the MCP server with the denied processor removed, then reinstate it and confirm the complete pipeline in one of the surfaces above. The normalization behavior verified remotely does not change when the processor is added back.
Request Limits
A single request body is capped at 16 MB. The cap covers the whole JSON-RPC request, so it applies to the pipeline YAML, the sample log, and the expected fixture together rather than to each one individually. Exceeding it surfaces as a request error rather than a pipeline failure. Sample logs are the usual cause: a few representative events exercise a pipeline as thoroughly as a large capture, and keep the call well inside the limit.
Each call carries exactly one JSON-RPC request. Trailing data after the first request is rejected as a parse error, so a client that batches several requests into one body will see a parse error rather than partial results.
Transport Behavior
The endpoint accepts POST only, at the /mcp path. A GET is refused with a method error, and other paths are not served. A separate /healthz path answers liveness checks.
The engine behind the endpoint scales to zero after ten minutes of inactivity. The first call after a quiet period therefore includes a cold start and takes noticeably longer than the calls that follow it; subsequent calls hit a warm engine. This is normal operation rather than a fault, and it needs no action beyond allowing for it in a client timeout.