Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Pattern examples

log10x_pattern_examples
Read-onlyIdempotent

Pull recent live log events for a pattern from Splunk, Datadog, Elasticsearch, or CloudWatch, grouped by templateHash with extracted slot values. Use for 24-hour event evidence.

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; the stable pattern identity is the tenx_hash carried on each bucket), 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 is honest about 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

TableJSON Schema
NameRequiredDescriptionDefault
viewNoResponse 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
limitNoMaximum number of sample events per templateHash bucket. 1-50, default 10.
scopeNoVendor-specific scope (Splunk index, Datadog index, ES index pattern, CloudWatch log group). Defaults to a sensible per-vendor value when omitted.
vendorNoLog analyzer to search. Auto-detected when exactly one of the supported vendors has credentials in the env; pass explicitly when multiple are configured.
patternNoPattern 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.
serviceNoOptional service-name scope. Translated to the vendor-specific service filter.
severityNoOptional severity scope (e.g., `ERROR`, `WARN`).
bucket_idNoBucket 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.
timeRangeNoWindow 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
environmentNoEnvironment nickname.
slot_filterNoOptional 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_hashNoCanonical 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

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
toolYes
viewNosummary
imagesNo
actionsNo
summaryYes
warningsNo
truncatedNo
next_cursorNo
render_hintNo
generated_atYes
schema_epochYes
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.30.7

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, openWorldHint, idempotentHint), and the description goes well beyond them: SIEM phrase-search probe, local templater pass, Jaccard ≥0.85 discrimination, top-buckets-by-count ordering, explicit parseFailed markers, and head-line-only warnings 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?

Dense but front-loaded: the core action and 24h constraint come first, with alternatives and orchestration role after. Some clauses (templater-path recap, similarity threshold mechanics) are verbose, but every sentence carries operational information.

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?

An output schema exists, so return-value detail is not required, and the description still covers partial-extraction semantics, retention limits, and the orchestration contract. For a 12-param open-world tool, nothing an agent needs to call it correctly is missing.

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 explains view, bucket_id, timeRange, slot_filter, etc. The description restates the pattern/pattern_hash duality and the 24h cap but adds no syntax or format detail beyond what the schema provides, matching the baseline 3.

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 (pull recent live events) and resource (for a pattern), names the supported log analyzers, and explicitly distinguishes itself from log10x_retriever_query, log10x_event_lookup, and log10x_pattern_trend. An agent can identify the tool's role without opening a schema.

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?

Gives explicit when-to-use ('orchestration primitive called by log10x_investigate when the chain needs concrete event evidence'), when-not (bounded to 24h; use log10x_retriever_query for older history), and preferred alternatives for single-line inspection.

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