Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Metrics that moved

log10x_metrics_that_moved

Read-onlyIdempotent

Identify customer metrics that changed during a Log10x pattern or customer-metric anchor by comparing high/low phase means, filtering candidates for shape-similarity ranking.

Instructions

First step of cross-pillar investigation: deterministic filter on which customer metrics actually moved while an anchor was active. Anchor is either a Log10x pattern (anchor_type: "log10x_pattern") OR a customer metric expression (anchor_type: "customer_metric"); candidates are all sibling series from the OTHER pillar. Partitions the anchor's window into high-phase / low-phase buckets by median rate and keeps only candidates whose mean value differs ≥15% between the two phases. Returns moved[], not_moved[], evaluation_failed[] — no Pearson, no tier, no causal framing. This is the cheap deterministic cut that pares the candidate set before the more expensive shape-similarity pass. Compose with log10x_rank_by_shape_similarity and log10x_metric_overlay.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`step`	No	Bucket step.	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	Time window. Alias: `timeRange`.	1h
`timeRange`	No
`candidates`	Yes	Customer-side PromQL expressions to evaluate (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. Pre-filter with `metrics_sharing_resource` or label-scoped `customer_metrics_query` queries.
`anchor_type`	Yes	Anchor side. `log10x_pattern` = anchor is a 10x pattern. `customer_metric` = anchor is a customer PromQL.
`environment`	No
`phase_gap_floor`	No	Relative gap floor between anchor-high and anchor-low phase means. Candidate is "moved" iff its gap ≥ this. Default 0.15 (=15%) is an uncalibrated default — output is tagged `unvalidated_default` until a caller-side calibration overrides it. 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

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

Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: it explains the median-rate phase partitioning, the ≥15% gap rule, the returned arrays (`moved[]`, `not_moved[]`, `evaluation_failed[]`), and explicitly states what it does not do ('no Pearson, no tier, no causal framing'). The annotations already cover read-only/idempotent safety, and the description does not contradict them.

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 description is front-loaded with the purpose and workflow role, then adds algorithm and return details. It is dense but largely earns its space; the only minor redundancy is the repeated emphasis on 'deterministic' and 'cheap' across two sentences.

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 complex 11-parameter tool with an output schema and rich annotations, the description supplies the investigation context, algorithm, outputs, and composition guidance an agent needs. It does not need to re-explain return values because an output schema exists, but it still orients the caller correctly.

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?

With 64% schema coverage, the schema carries much of the parameter detail, but the description adds conceptual meaning: it defines the anchor/candidate pillar relationship ('candidates are all sibling series from the OTHER pillar') and clarifies the anchor_type branches. It also implies the phase-gap-floor behavior. It does not document every parameter, but it adds value beyond the schema for the core semantics.

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 states a specific verb and resource — a deterministic filter on which customer metrics moved while an anchor was active — and distinguishes the tool from siblings by naming the expensive shape-similarity pass it precedes. An agent can identify the tool's role in cross-pillar investigation 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?

It explicitly frames the tool as the 'first step' and 'cheap deterministic cut' to use before 'the more expensive shape-similarity pass', and it names the two composition tools (`log10x_rank_by_shape_similarity`, `log10x_metric_overlay`). This gives clear when-to-use and sequencing guidance with named alternatives.

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

Deploy Server