Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Rank by shape similarity

log10x_rank_by_shape_similarity

Read-onlyIdempotent

Ranks candidate metrics by Pearson correlation and signed lag against an anchor, revealing which ones match in shape and their lead/lag timing.

Instructions

Second step of cross-pillar investigation: Pearson correlation + signed lag on a pre-filtered candidate set (typically the moved[] output of log10x_metrics_that_moved). Returns per-candidate: pearson_magnitude, pearson_signed (direction preserved), lag_seconds (signed: negative = candidate leads anchor, positive = candidate lags), lag_at_bound (flag: peak landed at search-window boundary), lag_tightness (how sharply the Pearson surface peaks), anchor_phase_gap, anchor_phase_aligned (flag: candidate value differs ≥15% between anchor's high-phase and low-phase buckets), n_buckets. No tier, no causal label: the agent reads the flags and decides. Compose with log10x_metric_overlay for the final per-candidate aligned-timeseries view.

Input Schema

Name	Required	Description	Default
`step`	No		30s
`anchor`	Yes	Anchor identity. For `anchor_type=log10x_pattern`: the pattern Symbol Message NAME or its 11-char `pattern_hash` (= `tenx_hash`), the tool detects shape and queries the correct PromQL label (`message_pattern` vs `tenx_hash`). For `anchor_type=customer_metric`: a customer PromQL expression.
`window`	No		1h
`timeRange`	No
`candidates`	Yes	Customer-side PromQL expressions to rank (max 100). An AI caller reasoning over results can't meaningfully digest more than a few dozen; the cap reflects that, not a backend constraint.
`anchor_type`	Yes
`environment`	No
`lag_search_max_abs`	No	Maximum absolute lag in seconds to scan. Default 1800s: uncalibrated. Output is tagged `unvalidated_default` when used as-is. Narrow it when the use case has a known tighter upper bound on cascade latency (e.g. 300 for sub-5-min cascades). See `docs/cross-pillar-primitives.md` for the calibration playbook.
`customer_metrics_url`	No	Per-call override for the customer metrics backend URL. Wins over LOG10X_CUSTOMER_METRICS_URL env var. Use when MCP was launched with an empty/stale URL.
`customer_metrics_auth`	No
`customer_metrics_type`	No
`anchor_phase_aligned_floor`	No	Relative phase-gap floor for the `anchor_phase_aligned` flag. Default 0.15: uncalibrated, same provenance caveat as lag_search_max_abs.

Output 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.

Changed3 schema fields changedv1.30.8Oct 15, 2026

changedInput schema / properties / anchor / description

Previous value: -"Anchor identity. For `anchor_type=log10x_pattern`: the pattern Symbol Message NAME or its 11-char `pattern_hash` (= `tenx_hash`) — the tool detects shape and queries the correct PromQL label (`message_pattern` vs `tenx_hash`). For `anchor_type=customer_metric`: a customer PromQL expression."New value: +"Anchor identity. For `anchor_type=log10x_pattern`: the pattern Symbol Message NAME or its 11-char `pattern_hash` (= `tenx_hash`), the tool detects shape and queries the correct PromQL label (`message_pattern` vs `tenx_hash`). For `anchor_type=customer_metric`: a customer PromQL expression."

changedInput schema / properties / anchor_phase_aligned_floor / description

Previous value: -"Relative phase-gap floor for the `anchor_phase_aligned` flag. Default 0.15 — uncalibrated, same provenance caveat as lag_search_max_abs."New value: +"Relative phase-gap floor for the `anchor_phase_aligned` flag. Default 0.15: uncalibrated, same provenance caveat as lag_search_max_abs."

changedInput schema / properties / lag_search_max_abs / description

Previous value: -"Maximum absolute lag in seconds to scan. Default 1800s — uncalibrated. Output is tagged `unvalidated_default` when used as-is. Narrow it when the use case has a known tighter upper bound on cascade latency (e.g. 300 for sub-5-min cascades). See `docs/cross-pillar-primitives.md` for the calibration playbook."New value: +"Maximum absolute lag in seconds to scan. Default 1800s: uncalibrated. Output is tagged `unvalidated_default` when used as-is. Narrow it when the use case has a known tighter upper bound on cascade latency (e.g. 300 for sub-5-min cascades). See `docs/cross-pillar-primitives.md` for the calibration playbook."

First observedv1.30.7Sep 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower, yet the description adds real behavioral context: it discloses that there is 'no tier, no causal label' and that the agent must interpret the returned flags itself, which sets expectations about the tool's epistemic limits. It also explains what each returned flag means (lag sign convention, boundary flag, phase-alignment threshold).

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 workflow position is front-loaded in the first clause, followed by the mechanics and then the output contract. The long enumeration of returned flags is dense but each item carries distinct meaning; only minor trimming is possible.

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 it did not need to explain return values, yet the flag semantics it provides are genuinely useful for interpretation. The main gap is the unlabeled parameters (step, window, timeRange), which an agent must infer, but for the intended workflow the description is otherwise complete.

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 description coverage is 42%, and several parameters (step, window, timeRange, environment, customer_metrics_auth, customer_metrics_type) are undocumented anywhere. The description adds meaning for `candidates` ('pre-filtered candidate set') and the lag search window implicitly through `lag_at_bound` and `lag_seconds` semantics, but it does not compensate for the full coverage gap, so the baseline 3 is appropriate.

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 names a specific operation (Pearson correlation + signed lag ranking) on a specific resource (a pre-filtered candidate set) and explicitly positions it as the 'second step of cross-pillar investigation' after log10x_metrics_that_moved. This lets an agent distinguish it from siblings like log10x_metric_overlay and log10x_metrics_that_moved without opening any schema.

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?

It clearly states when to use it (on the `moved[]` output of log10x_metrics_that_moved) and how to compose it (with log10x_metric_overlay for the aligned-timeseries view). It stops short of an explicit when-not or naming an alternative ranking path, so it is strong context rather than full routing guidance.

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

Deploy Server