Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Event lookup

log10x_event_lookup
Read-onlyIdempotent

Resolve a raw log line or pattern name to its stable pattern identity and see service volume, cost share, first-seen, AI class, recommended action, and offload status.

Instructions

Resolve a raw log line or pattern name to its stable pattern identity (the hash of its representing-token subset), then return byte volume + share per service (with cost overlay when $/GB is set), before→after delta, first-seen timestamp within the observation window, an AI classification (error/debug/info) with a recommended action (filter/keep/reduce), and the current offload disposition (pass / sample / compact / drop) read from the Reporter routeState label. Call this first whenever a user pastes a SINGLE log line and asks "what is this", "is this new", "is this safe to drop", or "is this being dropped / offloaded". The lookup is structural, not byte-exact — different timestamps/request IDs/user IDs on the same underlying pattern resolve to the same identity. If no match is returned, say so honestly. Use log10x_resolve_batch instead when the user pastes MULTIPLE events, a SIEM dump, or a batch to triage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patternNoPattern name or search term to look up (e.g., "Payment_Gateway_Timeout"). Omit when passing `pattern_hash` / `tenxHash` instead.
serviceNoService to scope the lookup
tenxHashNoLegacy alias of `pattern_hash`. Both are accepted. Pass either the canonical `pattern_hash` form or this legacy form — they are treated identically.
siemScopeNoSIEM scope for the live sample line on a tenxHash reverse lookup: a CloudWatch log group (`/aws/ecs/my-svc`), ES index, or Splunk index. When omitted, the detected SIEM connector uses its own default scope. Only consulted when `tenxHash` was passed (the cross-pillar correlation case).
timeRangeNoTime range. Sub-day values for incident-window lookups. '24h' and '1d' are equivalent.7d
environmentNoEnvironment nickname
analyzerCostNoSIEM ingestion cost in $/GB (deprecated alias of `effective_ingest_per_gb`)
pattern_hashNoCanonical 11-char hash seen on a SIEM / CloudWatch Logs event (e.g. "03ndjreM-sU"). Alias of `tenxHash`; both are accepted. Resolved against the 10x metrics to recover the pattern, then the normal cost/services breakdown is shown.
effective_ingest_per_gbNoCustomer-supplied SIEM ingest cost in $/GB. When set, dollar fields populate with rate_source=customer_supplied; when absent and no list rate is detected, dollar fields collapse to null and rate_source=unset.

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 only cover the safety profile (readOnly/openWorld/idempotent), so the description carries the rest and does: it discloses the matching is structural rather than byte-exact (timestamps/IDs collapse to one identity), the offload disposition comes from the Reporter `routeState` label, cost fields only populate when $/GB is set, and that a no-match should be reported honestly.

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-loads the identity-resolution purpose before the return payload and the call-first guidance, and every clause maps to a real behavior. The long enumeration of returned fields is dense but it is the part that differentiates this tool, so it earns its space.

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 tool with full schema coverage, an output schema, and annotations, the description supplies the remaining decision-relevant context: when to call it, when not to, the structural-match caveat, and the honesty requirement on no-match.

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 coverage is 100% and the schema itself already documents aliasing (tenxHash/pattern_hash), the cost-rate source semantics, and the siemScope default, so the description adds little beyond repeating 'cost overlay when $/GB is set'. Baseline 3 applies when the schema does the heavy lifting.

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+resource (resolve a raw log line or pattern name to a stable pattern identity) and enumerates the returned payload, so the agent knows exactly what comes back. It also names the sibling it is not (log10x_resolve_batch), making the split unambiguous.

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?

Explicit trigger conditions: 'Call this first' when a user pastes a SINGLE log line and asks 'what is this', 'is this new', 'is this safe to drop', or 'is this being dropped'. It then names the exclusion case (MULTIPLE events, SIEM dump, batch triage) and routes to log10x_resolve_batch.

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