Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Discover join label

log10x_discover_join
Read-onlyIdempotent

Auto-detect the best structural join label between Log10x pattern metrics and a customer metrics backend via Jaccard similarity, caching the result per session for reuse.

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

TableJSON 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

TableJSON 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. First observedv1.30.7

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses the session caching keyed by (environment, endpoint), reuse semantics across primitives, threshold behavior (0.7 primary / 0.5 runner-ups), and the exact fallback shape (`no_join_available` with probed-label matrix). This is rich context the annotations cannot convey.

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-loads what the tool does, then the caching model, then the routing guidance, then the no-join fallback. Every sentence carries information, though the description is on the longer side for a tool that agents are told not to call directly.

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?

Given an output schema exists, return values need not be explained, yet the description still characterizes the no-join fallback. Together with the caching and routing guidance, an agent has everything needed to decide whether and how to invoke it.

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 100% schema coverage the parameter documentation is already thorough, so the baseline is 3; the description adds value by naming the caching key (environment, customer-backend-endpoint) and restating the threshold semantics that tie parameters to behavior. It does not add much syntactic detail beyond the schema, keeping it from a 5.

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+resource ('auto-discover the structural join label') and explains the mechanism (Jaccard similarity on label value sets). It is clearly distinguishable from the sibling log10x_discover_labels, which handles label discovery rather than cross-pillar join resolution.

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 tells the agent 'normally NOT need to call this tool directly' because the primitives (metrics_that_moved, rank_by_shape_similarity, metric_overlay) call it internally, and reserves direct use for power users wanting to inspect the join universe or force re-discovery. This is clear when-to-use, when-not-to-use, and who-else-uses-it guidance.

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