Most observability servers stop at search. What is interesting here is the pipeline loop, and specifically that it is honest about its own gap: a configuration that validates is not a configuration that transformed the data. Live capture closes that by sampling real before-and-after items from nodes on running agents, and the dry-run tools cover the other side by showing what a processor will emit before anything is saved at all. Write tools are labelled as such, and the token you issue is where that boundary actually gets drawn.
Edge Delta's own server, with 28 tools across two halves: querying observability data with CQL, and managing the telemetry pipelines that produce it — including sampling real before-and-after data from running agents to confirm a change actually took effect.
- discover_schema returns the filterable fields for a scope with sample values and a CQL reference; build_cql constructs a valid query from structured filters and validate_cql checks one before it runs, catching unknown fields and unsupported regex
- Search across the platform — get_log_search, get_metric_search, get_event_search, get_log_patterns and get_trace_timeline — with lookback as a Go duration and from and to as ISO 8601 timestamps
- Graph counterparts for the shape over time rather than the individual items: get_log_graph, get_metric_graph, get_trace_graph and get_pattern_graph
- facets and facet_options expose the dimensions available and the values inside them, and search_metrics does a fuzzy match on metric names before the tools that need an exact one
- Pipeline changes follow a deliberate loop: read the config, validate it without saving and get back valid with a reason, save it as a new version that is not yet deployed, then deploy to the fleet — with revert_pipeline to return to an earlier saved version and get_pipeline_history to see them all
- Live capture answers what validation cannot: start_pipeline_capture samples real data flowing through chosen nodes on running agents, get_pipeline_capture_status polls per agent, and get_pipeline_capture_results returns before and after per node so a transformation is confirmed rather than assumed
- Dry runs cover the opposite direction — test_pipeline_ottl runs OTTL statements against sample OTEL log items and returns the transformed items, and test_pipeline_node dry-runs a whole processor node such as log_to_metric, log_to_pattern, extract_metric, parse_json_attributes, grok or mask, with no save, no deploy and no live traffic
- get_all_dashboards and get_dashboard read the dashboards the organisation already has, and get_ingestion_endpoint returns where data goes in
- Every tool is documented as read-only or write, so deciding which token permissions to grant is a decision you can actually make rather than guess at
A Go server distributed as a container image, so Docker Engine 20.10 or newer with the Buildx plugin available — included with Docker Desktop on macOS and Windows, installed separately on most Linux distributions. It authenticates to Edge Delta with an API token, and that token's permissions are what decide how much of the write half is reachable: the read-only tools never change anything in the organisation, while the write tools create pipeline versions and deploy them to the fleet.
One command plus a key — claude mcp add --transport http edgedelta "https://api.edgedelta.com/v1/orgs/YOUR_ORG_ID/mcp?token=YOUR_API_TOKEN", then supply credentials