Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Find skew

log10x_find_skew

Read-onlyIdempotent

Identify patterns where one slot value dominates events to surface sampling opportunities, reducing log volume while retaining signal.

Instructions

Identify patterns where one slot value dominates the field (>= 60% of events by default). Surfaces sampling opportunities: "slot verb is get 78% of events — sample the get case at 1/10 and save volume without losing signal." Differentiated against analyzer field histograms because the engine groups by per-pattern field-set, so dominance is measured within the structural pattern, not globally. Stage 1: accepts events as a paste array (same shape as log10x_resolve_batch). Calibration honesty: the 60% concentration floor and 1/10 sampling rate are hand-picked defaults tagged unvalidated_default in the output. The envelope surfaces the empirical observed_dominant_pct_distribution across all candidate slots so the agent can judge whether 0.6 is well above or below the noise floor for this dataset. See docs/cross-pillar-primitives.md for the agent behavior contract.

Input Schema

TableJSON Schema

Name	Required	Description
`top_n`	No	Number of findings to return. Default 20.
`events`	Yes	Events to analyze for slot skew. Same shape as log10x_resolve_batch — raw strings or JSON objects. Each event is templated locally; skew is computed across the resulting patterns.
`sample_n`	No	Sampling rate N for the savings projection (1/N of the dominant case kept). Default 10. Same calibration caveat — sample_n=10 is a defensible starting point but not validated for any specific cost target.
`min_events`	No	Minimum events per pattern to bother checking. Default 10 (filters low-sample noise).
`min_concentration`	No	Minimum dominant-value fraction for a slot to be flagged as skewed. Default 0.6 (a slot is "skewed" when one value is 60%+ of events). Hand-picked default tagged as `unvalidated_default` in the output. Compare against the `observed_dominant_pct_distribution` in `threshold_audit` to judge whether 0.6 is well above or below this dataset's noise.

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.4/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, closed-world), yet the description adds real behavioral context: thresholds are hand-picked and tagged `unvalidated_default`, and the envelope surfaces `observed_dominant_pct_distribution` so the agent can calibrate. It also references a docs contract for agent behavior. It does not describe output shape in detail, but the output schema exists to carry that.

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 the core definition and the example before the differentiation and calibration caveats. Dense but each sentence carries substantive information; the embedded quote and markdown formatting add mild length without much waste.

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?

Covers the technique, its scope relative to alternatives, the Stage 1 input constraint, and the calibration caveat, while an output schema already documents return values. An agent has enough to select and invoke it correctly without opening sibling tools.

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 meaning beyond the schema by framing min_concentration (0.6) and sample_n (1/10) as unvalidated calibration defaults and telling the agent to compare 0.6 against the observed distribution before trusting it. That interpretive guidance is not present in the 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 ('identify patterns where one slot value dominates the field') and immediately grounds it with a concrete example threshold (>= 60%). It explicitly distinguishes itself from analyzer field histograms by explaining that dominance is measured within per-pattern field-sets, which an agent cannot infer from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives a clear use context (surfacing sampling opportunities to save volume) and differentiates against the closest conceptual alternative (analyzer field histograms). It also flags the Stage 1 constraint of accepting a paste array. It stops short of stating when NOT to use it versus siblings like log10x_top_patterns or log10x_estimate_savings, so it is not a full 5.

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

Deploy Server