Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Investigate

log10x_investigate

Read-onlyIdempotent

Investigate any log line, pattern, service, or environment in one call to uncover root causes, returning causal chains or drift cohorts with confidence scores and verification commands.

Instructions

Single-call root-cause investigation for any log line, pattern, service, or environment. Returns a complete causal chain (for acute spikes) or co-drifter cohort (for gradual drift) with confidence scores derived mechanically from data signal quality, plus ready-to-run verification commands. Per-pattern blocks include offload_status (pass / sample / compact / drop) so the narrative reflects whether the receiver is admitting or dropping the implicated patterns, matching top_patterns and pattern_trend. Call whenever the user asks 'what is going on with X', 'why is X spiking', 'investigate X', or pastes a log line / alert and asks for diagnosis. Input is the user's natural-language target: pass their words verbatim. The tool detects whether the input is a raw log line, pattern identity, service name, or 'environment' and runs the appropriate flow. It also detects whether the trajectory is acute or gradual drift and renders a different report shape for each. Confidence percentages decompose into named sub-scores (stat × lag × chain for acute; slope_sig × cohort for drift): walk the user through the decomposition when asked. Show the entire markdown report to the user without modification.

Input Schema

Name	Required	Description	Default
`depth`	No	`shallow`: anchor service only. `normal` (default): anchor service + immediate dependencies. `deep`: full environment-wide.	normal
`window`	No	Analysis window. Defaults to `1h` for acute-spike cases; `30d` recommended for drift cases. Accepts any PromQL-style duration string (`15m`, `1h`, `6h`, `24h`, `1d`, `7d`). Alias: `timeRange`. If neither is set, defaults to `1h`; if both are set, `window` wins.
`timeRange`	No	Alias for `window` for consistency with other Log10x tools. If both are set, `window` wins.
`use_bytes`	No	Use byte-based rate instead of event-count. Event-count is strongly preferred; use only if the Reporter does not emit the count metric.
`environment`	No	Environment nickname: required in multi-env setups.
`starting_point`	Yes	The user's target, verbatim. Can be a raw log line, a pattern identity (symbolMessage or tenx_hash), a service name, or the literal string "environment"/"all"/"audit". The tool detects the mode automatically.
`baseline_offset`	No	Offset for the baseline comparison. Defaults to `24h` for short windows (acute-spike cases) and to the same value as `window` for long windows (≥7d, drift cases). Override only if you need a non-standard comparison.

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.

Changed1 schema field changedv1.30.8Oct 15, 2026

changedInput schema / properties / environment / description

Previous value: -"Environment nickname — required in multi-env setups."New value: +"Environment nickname: required in multi-env setups."

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 only cover safety (readOnly, idempotent, openWorld), and the description adds substantial behavior: dual output shapes (causal chain vs co-drifter cohort), automatic input-mode detection, acute-vs-drift trajectory detection, confidence decomposition into named sub-scores, and offload_status semantics tied to top_patterns/pattern_trend. It even instructs the agent to present the markdown report unmodified, which is real operational context beyond the structured fields.

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?

It is long but front-loaded: the first sentence delivers the core purpose and deliverable before expanding into triggers, mode detection, and output morphology. Most sentences earn their place, though the confidence-decomposition and report-presentation instructions are somewhat stacked and could be tightened.

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?

Given the tool's high complexity, a rich 7-param schema, and an existing output schema (so return values need no explanation here), the description covers mode detection, output shapes, confidence mechanics, and usage triggers. An agent has everything needed to select and invoke it correctly.

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 the baseline is 3, but the description meaningfully clarifies the required starting_point ('pass their words verbatim', auto-detected mode) and explains what the tool does with it, adding intent the schema alone does not convey. The optional params (depth, window, etc.) are already fully documented in the schema and get no extra treatment here.

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 ('Single-call root-cause investigation for any log line, pattern, service, or environment') and immediately names the deliverable ('complete causal chain ... or co-drifter cohort ... plus ready-to-run verification commands'). It also carves out a distinct role as a single-call orchestrator that internally runs the appropriate flow, setting it apart from narrower siblings like log10x_pattern_trend or log10x_top_patterns.

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 explicit trigger phrases ('what is going on with X', 'why is X spiking', 'investigate X', pasting a log line/alert) which tells the agent precisely when to reach for it. However, it offers no when-not-to-use guidance and never names an alternative sibling for cases the agent might prefer (e.g., a single-trend lookup).

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

Deploy Server