Skip to main content
Glama
log-10x

Log10x MCP Server

Official

Pattern trend

log10x_pattern_trend
Read-onlyIdempotent

Track a log pattern's volume history over a chosen window with spike detection to determine if it is worsening, when it started, or if it spiked 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: kept (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 kept-only with total volume.

Input Schema

NameRequiredDescriptionDefault
stepNoData point interval. Default `auto` sizes the step to give about 12 to 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 (the 11-character pattern hash 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

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. Changed4 schema fields changedv1.30.8
    • changedInput schema / properties / pattern / description
      Previous value: -"Pattern name (e.g., \"Payment_Gateway_Timeout\"). Provide either pattern or pattern_hash — pattern_hash is preferred when available (skips a metrics lookup)."New value: +"Pattern name (e.g., \"Payment_Gateway_Timeout\"). Provide either pattern or pattern_hash: pattern_hash is preferred when available (skips a metrics lookup)."
    • changedInput schema / properties / pattern_hash / description
      Previous value: -"The tenx_hash of the pattern (11-char stable identity from top_patterns / preview_filter). Preferred over pattern when available."New value: +"The tenx_hash of the pattern (the 11-character pattern hash from top_patterns / preview_filter). Preferred over pattern when available."
    • changedInput schema / properties / step / description
      Previous value: -"Data 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."New value: +"Data point interval. Default `auto` sizes the step to give about 12 to 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."
    • changedInput schema / properties / view / description
      Previous value: -"Output format. Always \"summary\" — the structured envelope. Field retained for backward-compat."New value: +"Output format. Always \"summary\": the structured envelope. Field retained for backward-compat."
  2. First observedv1.30.7

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower. The description adds genuinely new behavioral context: the envelope reports which cohort the series represents, `both` adds a parallel dropped_time_series and dropped_share_pct, and the reporting discipline about stating the observation window. It stops short of describing pagination or response size limits beyond the include_chart caveat.

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?

Purpose and trigger conditions are front-loaded before the cohort details, and most sentences carry actionable content. It is long, and the include-cohort explanation partially duplicates the schema's own enum descriptions, which is the only real inefficiency.

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 10-parameter read-only analytics tool with a full output schema, the description covers what the schema cannot: sequencing relative to a sibling, the natural-language triggers, cohort-scoping intent, and the reporting constraint against over-claiming history. Return-value detail is correctly delegated to the output schema.

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 schema already documents all ten parameters in depth (including the auto-step sizing, cohort enums, and the projection semantics of monthly_volume_gb). The description restates the include cohort meanings and the analyzerCost cost overlay, adding framing but little syntax or meaning the schema lacks. Baseline 3 is appropriate 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?

The description gives a specific verb and resource — returns volume history for a single pattern over a chosen window — plus the value-adds (sparkline, spike detection, byte-volume ranking, cost overlay). It distinguishes itself from log10x_event_lookup by naming the sequencing ('Call this after log10x_event_lookup'), so an agent can route correctly 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?

Explicit triggers are quoted ('is this getting worse', 'has it been louder before', 'when did it start'), an ordering constraint is stated (after log10x_event_lookup), and each `include` cohort is tied to a use case ('verify post-deploy realised savings', 'chart what we are offloading right now', overlay kept vs dropped). When-not-to-claim guidance ('never claim history older than the window') is also present.

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