Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Diff env doc vs LOG10X_* env vars

log10x_env_diff_vs_envvars

Read-onlyIdempotent

Compare the stored env-config document against LOG10X_* environment variables to expose per-field disagreements and resolve silent overrides at boot.

Instructions

Compare the stored env-config document against the LOG10X_* environment variables the env-var bridge would have produced, and report per-field disagreements with remediation recommendations. Call this when the user says "but I set the env var" or downstream tools report a value the user thinks they overrode — the on-prem store wins over env vars per resolver precedence, and silent-override is the most common boot-time surprise. Args: env_id (required — env_id UUID or nickname). For each disagreeing field (env_id, nickname, cluster., destination., streamer., retriever., offload_destinations[0].), returns { field, stored, envvar, recommendation }. The recommendation tells the user to either unset the LOG10X_ env var (preferred — on-prem store is the source of truth) or to update the stored doc via the matching setter (log10x_dest_set for destination, log10x_set_gitops_repo for gitops). Pure-on-prem-store configs (no LOG10X_* env vars set) return ok:true with an empty diff and a note that no ambiguity is possible.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`env_id`	Yes	Env identifier — either the `env_id` UUID or the `nickname` from the env-config document. Resolved by walking the store chain (k8s → aws_ssm → gcp_sm → azure_ac → local).

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

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent), yet the description adds substantial behavior: resolver precedence, the silent-override failure mode, the per-field return shape, and the pure-on-prem edge case returning ok:true with an empty diff. That is well beyond what structured fields 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-loaded with the purpose, then the trigger condition, then args and return shape. It is dense but nearly every sentence carries distinct information; the field-list enumeration of disagreeing fields is the only mildly padded part.

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?

With an output schema present, the description need not explain return values, yet it still enumerates the diff fields and remediation guidance. Combined with the precedence rule and edge case, an agent has everything needed to call and interpret this tool.

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 there is a single parameter, so the schema already documents env_id as a UUID or nickname resolved through the store chain. The description merely restates that env_id is required and accepts a UUID or nickname, adding no new syntax or edge-case detail.

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 both operands: it compares the stored env-config document against the LOG10X_* environment variables the env-var bridge would produce, and reports per-field disagreements. This is clearly distinguishable from nearby siblings like log10x_env_validate or log10x_discover_env.

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?

Explicit triggering condition: 'Call this when the user says "but I set the env var" or downstream tools report a value the user thinks they overrode.' It also explains the underlying rule (on-prem store wins per resolver precedence) that makes this tool the right one in that situation.

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

Deploy Server