Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Pattern diff (set diff across a time boundary)

log10x_pattern_diff

Read-onlyIdempotent

Compare log patterns across adjacent time windows to find new, retired, persistent, and re-emerged patterns, plus deploy-like co-emergence clusters.

Instructions

Compare which log patterns are new, gone, persistent or back again between two adjacent time windows. Compares pattern presence in two windows (the most recent timeRange window as "after" vs the immediately preceding timeRange window as "before") and returns four sets: new (present after, absent before), retired (present before, absent after), persistent (present in both), and re_emerged (flagged as new but existed prior to the before-window, the "the bug we thought we fixed is back" case, derived by checking first_seen against the before-window boundary). Plus co_emergence_clusters: groups of 3+ patterns whose first_seen timestamps cluster within ±co_emergence_window_seconds (default 60s). That cluster is a deploy fingerprint: no CI/CD integration required; the agent can then query the customer's deploy system externally with the cluster timestamp. The two windows compare because a pattern's hash comes from the line, the symbol library and the engine configuration, not from what a query saw: under the same engine, library and configuration the same line carries the same hash in both windows. Use for "what changed since last deploy", "which patterns disappeared this week", "did the rollback bring back the old errors", or paired with log10x_pattern_examples on a flagged hash to see slot distribution. Scoping: service and severity narrow the universe; limit caps rows per category. Returns structured envelope under data.diff with the four sets plus an incidents block when co_emergence clusters are detected. An engine upgrade that changes the naming rules renames the patterns it affects once: across that boundary they show as new and their old names as retired, and the frequent ones form a co-emergence cluster at the upgrade time.

Input Schema

Name	Required	Description	Default
`view`	No	Output format.	summary
`limit`	No	Max rows per category (new / retired / persistent / re_emerged). Default 20.
`service`	No	Service name to scope. Omit for all services.
`severity`	No	Severity to scope (e.g. `ERROR`, `CRITICAL`).
`timeRange`	No	Window size on both sides of the boundary. The tool compares the most recent `timeRange` ("after") against the immediately preceding `timeRange` ("before"). Example: `timeRange: "1d"` compares today vs yesterday.	1d
`environment`	No	Environment nickname (for multi-env setups).
`analyzerCost`	No	stack ingestion cost in $/GB. Auto-detected from profile.
`co_emergence_window_seconds`	No	Time spread for clustering co-emergent patterns. Default 60s: tight enough to fingerprint a single deploy.
`min_co_emergence_cluster_size`	No	Minimum cluster size to emit. Default 3: 2 patterns sharing a timestamp is often coincidence.

Output Schema

Name	Required	Default
`data`	No
`tool`	Yes
`view`	No	summary
`images`	No
`actions`	No
`summary`	Yes
`warnings`	No
`truncated`	No
`next_cursor`	No
`render_hint`	No
`generated_at`	Yes
`schema_epoch`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.30.8Oct 15, 2026

changedInput schema / properties / co_emergence_window_seconds / description

Previous value: -"Time spread for clustering co-emergent patterns. Default 60s — tight enough to fingerprint a single deploy."New value: +"Time spread for clustering co-emergent patterns. Default 60s: tight enough to fingerprint a single deploy."

changedInput schema / properties / min_co_emergence_cluster_size / description

Previous value: -"Minimum cluster size to emit. Default 3 — 2 patterns sharing a timestamp is often coincidence."New value: +"Minimum cluster size to emit. Default 3: 2 patterns sharing a timestamp is often coincidence."

First observedv1.30.7Sep 11, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnly/openWorld/idempotent) cover the safety profile, but the description goes well beyond them: it explains the hash stability premise that makes window comparison valid, how re_emerged is derived from first_seen vs the boundary, what co_emergence clusters represent (deploy fingerprint), and the engine-upgrade rename edge case. That is unusually rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and set definitions, and nearly every sentence carries non-obvious information. It is long and there is mild redundancy between the opening sentence and the second sentence restating the window comparison, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, zero-required, output-schema-backed tool, it covers scoping, the boundary definition, cluster output structure, and a genuine operational edge case (engine upgrade renaming). Nothing an agent needs to invoke or interpret it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds semantic framing: service/severity "narrow the universe", limit caps rows per category, and it explains why the co-emergence knobs matter (60s tight enough to fingerprint a single deploy; 2 patterns sharing a timestamp is coincidence). This gives meaning beyond the field-level schema text for the clustering parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it computes a set diff of log patterns (new/retired/persistent/re_emerged) across a time boundary. It explicitly distinguishes itself from the sibling log10x_pattern_examples by naming it as a paired tool, so an agent can tell these apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggers: "what changed since last deploy", "which patterns disappeared this week", "did the rollback bring back the old errors", plus pairing with log10x_pattern_examples. It stops short of explicitly excluding near neighbors like log10x_pattern_trend or log10x_whats_changing, so sibling differentiation is mostly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server