Skip to main content
Glama
log-10x

Log10x MCP Server

Official

Discover join label

log10x_discover_join
Read-onlyIdempotent

Discovers the best joining label between Log10x pattern metrics and a customer metrics backend by scoring label-value overlap, enabling cross-pillar metric comparisons.

Instructions

Auto-discover the structural join label between Log10x pattern metrics and the customer metric backend. Runs Jaccard similarity on label value sets across candidate label pairs, returns the best pair above the 0.7 threshold plus runner-ups above 0.5. The result is cached per-session keyed by (environment, customer-backend-endpoint) so the cross-pillar primitives (metrics_that_moved, rank_by_shape_similarity, metric_overlay) can auto-run this once at session start and reuse the cached join without re-probing. Agents should normally NOT need to call this tool directly: the primitives call it internally. The explicit tool exists for power users who want to inspect the join universe or force a re-discovery after backend changes. When no pair crosses the threshold, returns a structured no_join_available response with the full probed-label matrix and recommended next actions.

Input Schema

NameRequiredDescriptionDefault
windowNoTime window for label value enumeration (e.g., "10m", "1h", "30m"). When set, both the Log10x and customer backends are queried with [now - window, now] filtering, excluding stale label values from series that stopped emitting samples. CRITICAL for environments with historical replay data, decommissioned pods, or otherwise orphan label values: stale values drag Jaccard down and cause false `no_join_available` refusals. Recommended: "10m" for steady-state clusters, "1h" for bursty traffic. Omit to include all-time values (default Prometheus behavior). Alias: `timeRange`.
timeRangeNoAlias for `window` for consistency with other Log10x tools.
environmentNoEnvironment nickname (for multi-env setups).
force_refreshNoWhen true, bypass the session cache and re-run the Jaccard pass against the live backends.
minimum_jaccardNoMinimum Jaccard similarity to accept as a primary join. Default 0.7. Lower to 0.5 for exploratory discovery, 0.3 for noisy environments with historical stale values.
candidate_labelsNoOptional subset of customer-side labels to probe (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. When omitted, all labels from the customer backend are probed in preferred-first order.
customer_metrics_urlNoPer-call override for the customer metrics backend URL. Wins over LOG10X_CUSTOMER_METRICS_URL env var. Use this when the MCP server was launched with an empty/stale URL and you want to redirect to a reachable Prometheus without restarting the server.
customer_metrics_authNoPer-call override for the customer metrics auth credential (bearer token, API key, or apiKey/envId for log10x type).
customer_metrics_typeNoPer-call override for the customer metrics backend type. Defaults to generic_prom if customer_metrics_url is supplied without a type.

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. Changed1 schema field changedv1.30.8
    • changedInput schema / properties / window / description
      Previous value: -"Time window for label value enumeration (e.g., \"10m\", \"1h\", \"30m\"). When set, both the Log10x and customer backends are queried with [now - window, now] filtering, excluding stale label values from series that stopped emitting samples. CRITICAL for environments with historical replay data, decommissioned pods, or otherwise orphan label values — stale values drag Jaccard down and cause false `no_join_available` refusals. Recommended: \"10m\" for steady-state clusters, \"1h\" for bursty traffic. Omit to include all-time values (default Prometheus behavior). Alias: `timeRange`."New value: +"Time window for label value enumeration (e.g., \"10m\", \"1h\", \"30m\"). When set, both the Log10x and customer backends are queried with [now - window, now] filtering, excluding stale label values from series that stopped emitting samples. CRITICAL for environments with historical replay data, decommissioned pods, or otherwise orphan label values: stale values drag Jaccard down and cause false `no_join_available` refusals. Recommended: \"10m\" for steady-state clusters, \"1h\" for bursty traffic. Omit to include all-time values (default Prometheus behavior). Alias: `timeRange`."
  2. First observedv1.30.7

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), and the description adds substantial context beyond them: per-session caching keyed by (environment, customer-backend-endpoint), the 0.7/0.5 accept and runner-up thresholds, the orchestration role, and the structured `no_join_available` failure shape. This is exactly the cross-cutting behavior annotations cannot express.

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 purpose and mechanism, then the caching rationale and the usage directive. It is dense and slightly long, but nearly every sentence (thresholds, caching key, no_join_available) earns its place; minor redundancy in restating the 0.7 threshold already implied elsewhere.

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 9-param, zero-required tool with an output schema and full annotation coverage, the description supplies everything an agent needs: purpose, mechanism, caching semantics, orchestration position, and failure behavior. Nothing material is missing.

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 100% and the parameter docs are already rich (window, force_refresh, minimum_jaccard, overrides), so the schema carries the semantics. The description restates the 0.7/0.5 threshold behavior but adds no syntax or format detail beyond the schema; baseline 3 applies.

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 precise verb+resource: 'Auto-discover the structural join label between Log10x pattern metrics and the customer metric backend.' It names the mechanism (Jaccard on label value sets) and distinguishes itself from the sibling primitives that consume its result, so an agent can place it 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 routes the agent: 'Agents should normally NOT need to call this tool directly: the primitives call it internally,' then names the exception cases (inspecting the join universe, forcing re-discovery after backend changes). This is a textbook when/when-not statement.

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