Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Top patterns

log10x_top_patterns

Read-onlyIdempotent

Rank log patterns by byte volume and cost to pinpoint expensive or noisy events, with optional delta comparisons against a baseline window.

Instructions

Return the top N log patterns ranked by byte volume (with cost overlay when $/GB is set), optionally with a delta column vs a comparison_window baseline (week-over-week / day-over-day / 1h-vs-prior-1h). Use for "what is expensive right now", "what are the noisy patterns in this hour", "give me a snapshot of my loudest events", "what changed this week", "did the deploy add cost". Can be scoped by service label. timeRange accepts free-form <n><m|h|d> durations (e.g., 48h, 3d, 15m) — there's no enum snap. Pass comparison_window to get a per-row delta column; omit for current-rank-only. Pass include to choose which cohort to rank: admitted (default — what the receiver let through), dropped (the offloaded / overflow cohort alone), or both (total ingest pre-receiver). Use dropped for "what is the receiver throwing away" and both for an apples-to-apples pre/post comparison. Accepts siem_lens (what-if destination): keeps the real volumes, prices + gates for that destination at list rates, and stamps siem_actual vs siem_lens in the envelope. REQUIRES Reporter-tier metrics. Before anything is deployed, the POC tools answer the same question from your own logs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`view`	No	Output format. Always "summary" — the structured JSON envelope with patterns, incidents, totals, and chained-tool action hints. Field retained for backward-compat with callers that still pass `view: "summary"`.	summary
`limit`	No	Number of patterns to return. Default 10.
`offset`	No	Skip the first N patterns of the ranked result (for pagination). Default 0.
`include`	No	Which engine-decision cohort to scope to. `kept` (default) = events the engine forwarded as-is (routeState!="drop") — the pre-PL-12 behavior. `dropped` = events stamped routeState="drop" by the engine (the offload/down-tier cohort). `both` = the pre-decision union; per-row output adds kept_bytes / dropped_bytes / dropped_share_pct. Use `dropped` to verify post-deploy realised savings or to answer "which patterns are we offloading right now". Use `both` to compute the offload share denominator in a single call.	kept
`service`	No	Service name to scope the result. Omit for all services.
`verbose`	No	When true, every card carries the full forwarder snippet inline, every CTA renders unconditionally, and the volume-trend chart shows on every top-3 card. Default: compact mode (snippet templated once at top, CTAs gated to where they earn their line, chart only on ACUTE/NEW patterns).
`severity`	No	Severity level to scope the result (e.g., `ERROR`, `CRITICAL`, `DEBUG`).
`siemScope`	No	stack scope for the verbatim sample line on the top rows.
`siem_lens`	No	What-if destination lens: keep the real volumes, price the $/mo columns at this destination's list rates (env-configured rates never cross destinations). Envelope stamps siem_actual vs siem_lens.
`timeRange`	No	Time range to aggregate over. Default 1h.	1h
`environment`	No	Environment nickname (for multi-env setups).
`analyzerCost`	No	DEPRECATED — use effective_ingest_per_gb. stack ingestion cost in $/GB. Auto-detected from profile if omitted.
`include_chart`	No	Set include_chart=true to embed the rendered chart inline (large; default false to avoid response truncation).
`monthly_volume_gb`	No	What-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.
`effective_ingest_per_gb`	No	Customer-supplied $/GB rate used for the dollar overlay. When set, headline tags `rate_source=customer_supplied`. When absent, falls back to the profile list rate (`rate_source=list_price`) or omits dollars entirely (`rate_source=unset`).

Output Schema

TableJSON Schema

Name	Required	Default
`data`	No
`tool`	Yes
`view`	No	summary
`images`	No
`actions`	No
`summary`	Yes
`warnings`	No
`truncated`	No
`next_cursor`	No
`render_hint`	No
`generated_at`	Yes
`schema_epoch`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.30.7Sep 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses the Reporter-tier metrics requirement, the free-form timeRange syntax with no enum snap, the siem_lens what-if stamping (siem_actual vs siem_lens), and the projection semantics of monthly_volume_gb. These are real preconditions an agent would otherwise miss.

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-loaded with what the tool returns and heavily information-dense, with the sample-question list doing useful matching work. It is on the long side, but most sentences carry non-obvious constraint or routing information rather than restating the name.

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?

Output schema and annotations already cover return shape and safety, so the description focuses correctly on tier requirements, cohort semantics, and what-if/projection behavior. The main gap is its own inconsistency: it describes a `comparison_window` parameter and an `admitted` default that the schema does not contain.

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 already 100%, so the baseline is 3, and the description does add real value on timeRange syntax and cohort selection. However it introduces a naming mismatch that could cause a failed call: it says the default cohort is `admitted`, while the schema enum is `kept`, and it references a `comparison_window` parameter that does not exist in the input schema.

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 and resource ('Return the top N log patterns ranked by byte volume') plus the optional cost overlay and delta column. An agent can tell this apart from cost/savings siblings and from the POC tools without opening the 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?

Explicitly enumerates the triggering questions ('what is expensive right now', 'what changed this week', 'did the deploy add cost'), states when to pass or omit comparison_window, and gives distinct-use guidance for kept/dropped/both cohorts. It also routes pre-deploy callers to the POC tools as an alternative.

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

Deploy Server