Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Retriever query

log10x_retriever_query
Read-onlyIdempotent

Retrieve archived log events by stable pattern hash to recover data offloaded or aged out of SIEM retention, returning a preview and S3 results location.

Instructions

Forensic retrieval / rehydration from the Log10x Retriever archive (the customer's own S3 bucket) by the engine's STABLE pattern identity. The use case: events the receiver offloaded to the archive instead of the SIEM, or that aged out of SIEM retention, recovered by querying the stamped identity over a historical window. Pre-computed Bloom filters scope the scan to the matching pattern identity (tenx_user_pattern) so only relevant byte ranges are fetched (the moat: query-side token precision, not a full S3 scan). Matched events land as a list of *.jsonl objects in the customer's S3; the tool returns an in-context preview (capped by limit) PLUS data.results_location (the S3 bucket + prefix holding the full object set). A capable agent reads those objects directly to answer, or hands the S3 object list to the customer's own S3-to-SIEM path. No re-ingestion pipeline, no proprietary format. The envelope additionally carries per-pattern offload_status so retrieval results agree with the live metric-surface disposition (pass / sample / compact / drop) without a second tool call. Call for: events matching a pattern OUTSIDE SIEM retention; events filtered by a variable value that is not a faceted SIEM dimension (e.g. 'all payment_retry events for customer acme-corp 90 days ago'); compliance / audit / forensic exact retrieval; confirming what the receiver actually offloaded for a given pattern. Optional JavaScript filters refine over payloads after the Bloom-scoped fetch. For a time-bucketed series instead of raw events, use log10x_retriever_series. The envelope carries by_severity / by_service / by_day rollups with a rollup_basis provenance stamp (qrs_summaries = whole-match from engine summaries; events_capped = derived from the capped download).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd of the query window. Same grammar as `from`. Default `now`.now
fromYesStart of the query window. Accepts ISO8601 (`2026-01-15T00:00:00Z`), epoch millis, or relative (`now-1h`, `now-24h`, `now-7d`). Normalized to the engine's `now("-1h")` form before dispatch.
viewNosummary returns the typed envelope (data.events_matched, data.events[], data.query_id, data.diagnostics, data.human_summary). The deprecated markdown view was removed; data.human_summary carries the prose distillation for chat rendering.summary
debugNoEscalate the CloudWatch log level to DEBUG for THIS query only — per-blob Bloom decisions, per-fetch S3 reads, per-event results-writer samples. Use only when normal-run diagnostics cannot explain a 0-result or truncated outcome (volume is ~100x higher). Default false.
limitNoHard cap on events returned after merging per-worker result files. Default 500. Typical conversational queries want 10-100; the LLM will render only the first 50.
formatNo`events` (default: raw events), `count` (total + severity/service rollups, no event bodies), `aggregated` (events bucketed into a time series — use with bucket_size), `ephemeral_series` (bucketed series in Prometheus range-query shape for cross-pillar correlation). All four formats are rolled up client-side from the same events stream.events
searchNoBloom-filter search expression using the TenX subset: `==`, `||`, `&&`, `includes(field, "substr")`. Example: `severity_level=="ERROR" && includes(text, "ECONNREFUSED")`. Selective values are dramatically cheaper than open-ended scans. REQUIRED unless `pattern_hash` is given: the engine rejects a blank search, so there is no unscoped full-window scan. To scope to one pattern pass `pattern_hash`, which is matched as a text token; a Reporter-named `pattern` cannot be matched against the archive at all and is refused with a remedy.
targetNoTarget app/service prefix to scope the index scan. Defaults to __SAVE_LOG10X_RETRIEVER_TARGET__ (env var). Required if no default is configured.
filtersNoJavaScript filter expressions evaluated in-memory against each decoded event after the Bloom-scoped fetch. Full TenX JS API: `this.customer_id === "acme-corp"`, `this.http_code.startsWith("5")`. Filters are AND-combined.
patternNoReporter-named pattern (Symbol Message). NOT SUPPORTED against the offload archive: passing it returns an error naming the remedy, rather than a silent empty result. A Symbol Message is a label DERIVED from the event, so it is never a token in the archived bytes, and the Bloom index holds only text tokens plus template hashes. (The field this once queried, `tenx_user_pattern`, does not exist in the engine at all, which is why name-scoped queries returned BLOOM_REJECTED_ALL.) Pass `pattern_hash` instead: top_patterns returns it on the same row as the name, and event_lookup resolves a name to a hash.
bucket_sizeNoBucket size when format=aggregated or ephemeral_series. Examples: `1m`, `5m`, `1h`, `1d`.5m
environmentNoEnvironment nickname — required if multi-env.
pattern_hashNoCanonical pattern_hash from top_patterns / event_lookup. When provided, search is auto-built as `includes(text, "<hash>")` and no name resolution runs. It matches the stamped hash as a TEXT TOKEN because the archive re-derives its own `tenx_hash` field per multi-line group, so a field equality against a metrics-side hash matches nothing. This is the chain-stable identity emitted by top_patterns.payload.patterns[].pattern_hash — bypasses the name→hash resolver entirely. Precedence: `search` > `pattern_hash` > `pattern`. Example: `pattern_hash: "4Kjc7PHLWqY"`.
result_targetNoTier-1 result-sink redirect: write this query OUTPUT (events, summaries, markers) under tenx/<result_target>/ in the same bucket instead of the default target, e.g. to a prefix a SIEM connector watches. Omit to keep results under the scan target (default). Bare token [A-Za-z0-9_-]+.

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.7/5.0
Behavior5/5

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

Despite annotations already covering readOnly/openWorld/idempotent, the description adds real behavioral context beyond them: matched events land as *.jsonl in S3 while the tool returns a limit-capped preview plus data.results_location, offload_status agrees with the live disposition without a second call, rollups carry a provenance stamp, and debug escalates log volume ~100x. It discloses what gets returned and where, which annotations alone cannot.

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

Conciseness3/5

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

The content is dense and nearly every clause carries information, but it is delivered as a single sprawling paragraph with no structural separation of purpose, usage, and mechanics, making it hard to scan. A front-loaded one-line purpose followed by grouped sections would serve an agent better than this wall of text.

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 14-parameter tool with an output schema, the description is complete: it covers the retrieval model, the S3 result location, the offload_status agreement, the pattern_hash requirement, and the failure mode for 'pattern'. 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.

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 adds cross-parameter semantics the schema does not: why 'pattern' is refused against the archive (derived label, not a token), why pattern_hash matches as a text token, and the search > pattern_hash > pattern precedence. That is meaningful value on top of the schema rather than repetition.

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 ('Forensic retrieval / rehydration') and resource ('Log10x Retriever archive (the customer's own S3 bucket)') and immediately scopes it to engine stable pattern identity. It explicitly distinguishes itself from the sibling log10x_retriever_series ('For a time-bucketed series instead of raw events, use ...'), so an agent can separate them 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 Guidelines5/5

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

Provides an explicit 'Call for:' list of triggering conditions (events outside SIEM retention, non-faceted variable filtering, compliance/audit retrieval, confirming offloads) plus the named alternative for the series case. It even encodes the search/pattern_hash/pattern precedence, which routes the agent away from the unsupported 'pattern' path.

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