Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Pattern trend

log10x_pattern_trend
Read-onlyIdempotent

Track a single log pattern's volume history over a chosen window with sparkline and spike detection to see if it's worsening, when it started, or whether it's been louder before.

Instructions

Return the volume history for a single pattern over a chosen window (e.g. 1h, 24h, 7d, 30d), with a sparkline and spike detection — ranked by byte volume (with cost overlay when $/GB is set). Call this after log10x_event_lookup when the user asks "is this getting worse", "has it been louder before", "when did it start", or wants temporal context on a pattern surfaced in an earlier step. Always state the observation window explicitly in the reply — "flat at 2/h for the last 6 months of observation, spiked at 13:58 today" — and never claim history older than the window. Pass include to select the cohort: admitted (default), dropped (offloaded-only trend — useful for "is the receiver dropping more of this lately"), or both (total ingest). The envelope reports which cohort the series represents so the agent never conflates admitted-only with total volume.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepNoData point interval. Default `auto` sizes the step to give ~12–30 buckets per window (1h→5m, 6h→15m, 1d/24h→1h, 7d→6h, 30d→1d). Override only when a specific resolution is required; an over-coarse step (e.g. 1h on a 1h window) produces a 2-point series with no usable trend shape.auto
viewNoOutput format. Always "summary" — the structured envelope. Field retained for backward-compat.summary
includeNoWhich engine-decision cohort to scope the trend to. `kept` (default) = events that actually reached the destination (routeState=~"pass|", absence-tolerant). `dropped` = everything the receiver acted on, so everything the destination did NOT receive (offload | compact | tier_down | drop | sample). Pass `drop` for the literal hard-drop cohort alone. `both` = the pre-decision union; envelope adds a parallel `dropped_time_series` and `dropped_share_pct` so one call shows offload share over time. Use `dropped` to verify post-deploy realised savings or to chart "what we are offloading right now". Use `both` to overlay kept vs dropped on the same window.kept
patternNoPattern name (e.g., "Payment_Gateway_Timeout"). Provide either pattern or pattern_hash — pattern_hash is preferred when available (skips a metrics lookup).
timeRangeNoTime range. '24h' and '1d' are equivalent (one-day window). Sub-day values show fine-grained trajectory around an incident.7d
environmentNoEnvironment nickname
analyzerCostNoSIEM ingestion cost in $/GB
pattern_hashNoThe tenx_hash of the pattern (11-char stable identity from top_patterns / preview_filter). Preferred over pattern when available.
include_chartNoSet include_chart=true to embed the rendered chart inline (large; default false to avoid response truncation).
monthly_volume_gbNoWhat-if volume lens (forecast mode): model the environment at THIS monthly volume (decimal GB/month) instead of its measured volume. The real per-pattern shares and pattern mix are held fixed; only absolute bytes and dollars scale, by one uniform factor. Use it to project a prospect onto their own scale, or to forecast a real env after growth. Pairs with siem_lens. This is a PROJECTION: the envelope stamps volume_actual_gb vs volume_projected_gb and the scale factor, and the note points at the POC for the caller real patterns.

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

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

Annotations only declare read-only/idempotent/open-world, so the description carries the rest: it warns about conflating admitted-only with total volume, states the envelope reports the represented cohort, and discloses the projection stamping (volume_actual_gb vs volume_projected_gb). Some of the text is agent-facing output guidance rather than tool behavior, which slightly dilutes it.

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?

The purpose is front-loaded in the first sentence and the routing rule follows. It is long, but the length is largely earned by ten parameters and three cohorts; there is some duplication with the verbose schema descriptions for `include` and `step`.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering the safety profile, the description need not explain return values, and it covers when-to-use, cohort semantics, and the projection caveat. The only gap is the cohort-label inconsistency with the schema, which slightly weakens completeness.

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%, so the baseline is 3, and the description does add real semantic meaning (what kept vs dropped represent, the dropped_share_pct overlay, the what-if projection lens). However, it references enum values that do not exist in the schema – 'admitted' (schema default is 'kept') and 'drop' (schema value is 'dropped') – which partially undermines the added guidance.

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?

It states a specific verb and resource ('Return the volume history for a single pattern over a chosen window') plus the derived features (sparkline, spike detection, cost overlay). It positions itself relative to a named sibling, log10x_event_lookup, and its temporal-scope framing separates it from a generic pattern detail lookup.

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?

It gives explicit triggering conditions ('Call this after log10x_event_lookup when the user asks "is this getting worse"...') and names the predecessor tool. It also explains when to choose each `include` cohort ('dropped' to verify post-deploy savings, 'both' to overlay kept vs dropped).

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