Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Pattern examples

log10x_pattern_examples

Read-onlyIdempotent

Pull recent live events for a log pattern from Splunk, Datadog, Elasticsearch, or CloudWatch; group matches by templateHash with extracted slot values (24-hour window).

Instructions

Pull recent live events for a pattern from the customer's log analyzer (Splunk, Datadog, Elasticsearch, CloudWatch) and return them grouped by templateHash with template-extracted slot values per match. Bounded to a 24-hour window (live log analyzer retention); for older history use log10x_retriever_query. Input is either a Symbol Message (pattern name like Payment_Gateway_Timeout) or a pasted raw log line; pasted lines resolve via the same templater path as log10x_resolve_batch. The tool runs a SIEM phrase-search probe, runs returned events through the local templater, groups by templateHash (one bucket per template variant of the pattern; each bucket carries the pattern hash, tenx_hash), applies a content-token Jaccard similarity threshold (≥0.85) to discriminate the matching pattern's events from look-alikes, and returns the top buckets by event count. Output marks partial extractions: per-bucket templateHash labels, recall counts, and explicit parseFailed markers when slot extraction fails. Multi-line group templates report head-line-only with an explicit warning. Designed as an orchestration primitive called by log10x_investigate when the chain needs concrete event evidence after a metric-tier identification. Direct user-facing use is fine but rare; prefer log10x_event_lookup + log10x_pattern_trend for single-line inspection.

Input Schema

Name	Required	Description	Default
`view`	No	Response shape. `summary` (default) returns slim top-3 buckets (rank, template_hash, tenx_hash, event_count, jaccard, severity, service, recommended_action, headline, ~200-char sample_event preview) plus pattern-level counts. No raw_events, no full sample_event, no slot_distribution, no rationale prose. Target: under 8K tokens. `detail` returns one fully-hydrated bucket (requires bucket_id); pair with retriever_query for raw events.	summary
`limit`	No	Maximum number of sample events per templateHash bucket. 1-50, default 10.
`scope`	No	Vendor-specific scope (Splunk index, Datadog index, ES index pattern, CloudWatch log group). Defaults to a sensible per-vendor value when omitted.
`vendor`	No	Log analyzer to search. Auto-detected when exactly one of the supported vendors has credentials in the env; pass explicitly when multiple are configured.
`pattern`	No	Pattern name (e.g. `Payment_Gateway_Timeout`) or a pasted raw log line. Pasted lines resolve to the matching pattern via the same pattern-extraction path as log10x_resolve_batch. Either pattern or pattern_hash must be provided; pattern_hash is preferred when available.
`service`	No	Optional service-name scope. Translated to the vendor-specific service filter.
`severity`	No	Optional severity scope (e.g., `ERROR`, `WARN`).
`bucket_id`	No	Bucket identifier to fully hydrate. Accepts either the `template_hash` or the `tenx_hash` returned in a prior `view=summary` call. When supplied, the response carries one bucket with full sample_event, full slot_distribution (un-cropped sample_values), bucket_interpretation.rationale, and human_summary. Other buckets are omitted.
`timeRange`	No	Window for the live SIEM probe. Capped at 24h. To sample a pattern's offloaded cohort (events the Receiver routed to the overflow bucket, which the SIEM never received), use log10x_retriever_query. '1d' is a legacy alias for '24h'.	1h
`environment`	No	Environment nickname.
`slot_filter`	No	Optional slot-value filter. When provided, only buckets whose slot_distribution carries the given slot value pass through. Useful for drilling into a single dominant value from a previous pattern_examples call.
`pattern_hash`	No	Canonical 11-char hash. Either pattern (Symbol Message name) or pattern_hash must be provided; pattern_hash is preferred when available. Resolved to the pattern name via the 10x metrics (same path pattern_detail uses).

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.

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 already declare readOnly/openWorld/idempotent, and the description adds substantial behavioral context beyond that: the 24-hour retention cap, the SIEM phrase-search probe plus local templater pipeline, the 0.85 Jaccard discrimination threshold, per-bucket parseFailed markers, and head-line-only reporting with a warning for multi-line templates.

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 the core purpose and the 24-hour bound in the opening sentences, and every subsequent sentence carries real routing or behavioral information. It is dense and long, but given the 12-parameter surface and orchestration role most of the length is earned rather than padding.

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?

With an output schema present, return shapes need not be described, and the description still covers windowing, discrimination logic, partial-extraction markers, and sibling routing. For a tool of this complexity, 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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly (view, bucket_id, timeRange, slot_filter, etc.), establishing the baseline of 3. The description adds little parameter-level detail beyond what the schema provides, aside from reinforcing that input can be a pattern name or a pasted raw log line resolved via the templater path.

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 (pull recent live events for a pattern, grouped by templateHash with slot values) and explicitly names the vendor sources. It distinguishes itself from siblings by the 24-hour live-window bound and by naming log10x_retriever_query and log10x_event_lookup/log10x_pattern_trend as the alternatives for other cases.

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

Usage Guidelines5/5

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

Explicitly gives when-to-use and when-not-to-use: bounded to a 24-hour window, use log10x_retriever_query for older/offloaded history, and prefer log10x_event_lookup + log10x_pattern_trend for single-line inspection. It also frames the tool as an orchestration primitive invoked by log10x_investigate, telling the agent its intended call context.

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

Deploy Server