Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Install wizard

log10x_advise_install
Read-onlyIdempotent

Walk through installing Log10x Reporter or Receiver on Kubernetes: answer five prompts to choose app, forwarder, backends, airgap, and license, then get a Helm install plan.

Instructions

Progressive install wizard for the Log10x Reporter / Receiver on Kubernetes. This is the SINGLE entry point for installs — call it first. Do NOT call log10x_doctor or log10x_login_status as a pre-flight; the wizard handles login state, license acquisition, and demo-mode fallback internally, and surfacing the doctor's optional-capability warnings (Retriever, Datadog backfill, cross-pillar metrics) ahead of the install confuses users with concepts that are unrelated to deploying the Reporter/Receiver. Takes a snapshot_id from log10x_discover_env and walks the user through five decisions, asking one at a time and remembering each answer across turns (the snapshot's wizard session): (1) appreporter (dedicated DaemonSet forwarder, zero-touch) or receiver (sidecar inside the user's existing forwarder); (2) forwarder — Receiver-only, auto-picked when one is detected, asked when multiple; (3) backends — array of metrics destinations, can be multiple (e.g., ["log10x", "datadog"] to report to both SaaS + own backend simultaneously); (4) airgapped — opt-in CISO-friction reducer, conflicts only with "log10x" in backends (engine sends NOTHING to log10x.com); (5) license_jwt — auto-fetched from /api/v1/license/demo if the user is not signed in, or from /api/v1/license with the persisted Auth0 token if they are. Each call merges new args into the session and either asks the next question (returning a markdown prompt) or emits the final install plan once all answers are in. Demo + airgapped surfaces a soft warning (engine downgrades to online mode on demo licenses). Plan is plan-only: emits helm commands + values.yaml; the user runs them. Tier prerequisites: none — this is a pre-install tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoWhich Log10x app to install. **reporter** = a dedicated DaemonSet forwarder (zero-touch, runs alongside your existing forwarder); **receiver** = a sidecar plugged into your existing forwarder (filters/samples/compacts events in-flight). When omitted, the wizard asks the user.
actionNoPlan scope when the wizard is ready to emit. Default: `all`.
backendsNoWhere the engine emits TenXSummary metrics. Multi-destination — a user can report to log10x SaaS AND their own backend simultaneously, e.g. `["log10x", "datadog"]`. Choices: **log10x** (optional Log10x-hosted backend, for evaluation), **datadog**, **elastic**, **cloudwatch**, **prometheus** (customer-owned). The wizard pre-fills detected backends from the snapshot. The only mutual exclusion is `airgapped: true` + `"log10x"` in this list.
airgappedNoWhen true, the Log10x agents send nothing to log10x.com — engine metrics, license re-validation, and update checks all go silent. Use to reduce CISO friction. Conflicts with `"log10x"` in `backends` (the wizard surfaces the conflict). **Demo licenses cannot actually run airgapped** — the engine downgrades to online mode with a warning. The wizard surfaces this softly when both are picked.
forwarderNoReceiver-only: which detected forwarder kind to sidecar into. Auto-uses the snapshot's detected forwarder when there's exactly one; the wizard asks when there are multiple.
namespaceNoTarget namespace. Default: snapshot.recommendations.suggestedNamespace.
snapshot_idYesID returned by `log10x_discover_env`. The snapshot is cached for 30 min.
release_nameNoHelm release name. Default: `my-<app>` (e.g., `my-reporter`).
license_sourceNoHow the wizard should acquire the engine's license JWT. **Defaults to `"signin"`** when omitted — the wizard tries to mint a user-scoped license via the user's Auth0 session, and emits `signin_required` mode (chain through `log10x_signin_start` then re-invoke) when no session exists. Pass **`"demo"`** ONLY when the user explicitly asks for a quick 14-day anonymous demo (transient, can't run airgapped). Pass **`"paste"`** with `license_jwt_paste: "<jwt>"` when the user already has a JWT.signin
license_jwt_pasteNoLicense JWT supplied by the user when `license_source: "paste"`. Mints from `POST /api/v1/license` (signed-in) or `POST /api/v1/license/demo` (anonymous). Maps to the chart's license Secret.
backend_credentialsNoPer-backend credential configuration, keyed by backend kind (must be one of: log10x, datadog, elastic, cloudwatch, prometheus). **Only set for non-`log10x` backends** — `log10x` SaaS uses the license JWT and needs no extra credentials. Each entry has a `secretName` (the Kubernetes Secret the user creates out-of-band holding sensitive env vars like `DD_API_KEY`; default per backend is `<backend>-credentials`) and optional `plainValues` (overrides for non-sensitive env vars like `DD_SITE`). Example: `{ "datadog": { "secretName": "datadog-secret", "plainValues": { "DD_SITE": "us5.datadoghq.com" } } }`.

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?

Goes well beyond the annotations (readOnlyHint/idempotentHint/openWorldHint) by disclosing cross-turn session state ('merges new args into the session and ... remembering each answer across turns'), the plan-only contract ('emits helm commands + values.yaml; the user runs them'), license acquisition paths, the demo+airgapped downgrade warning, and 'Tier prerequisites: none.' These are behavioral facts 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-loaded: purpose and the routing rule occupy the first two sentences. However it is a dense, long block with heavy parenthetical asides, and several schema-level details are restated, so it is efficient rather than tight.

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 an 11-param, nested-object, stateful wizard with an output schema, the description covers the full decision flow, session semantics, prerequisites, and license paths. Since an output schema exists, no return-value explanation is needed, and nothing an agent needs to call it correctly appears to be missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds flow-level meaning the schema does not: the five-decision ordering, which decisions are auto-answered vs asked, the multi-destination example for backends, and the airgapped/log10x mutual exclusion. Useful added context without contradicting the schema.

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 up front ('Progressive install wizard for the Log10x Reporter / Receiver on Kubernetes') and explicitly positions itself against siblings: 'This is the SINGLE entry point for installs — call it first,' and names the tools it is not (log10x_doctor, log10x_login_status). An agent can discriminate this from the other ~50 log10x siblings 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?

Gives explicit when-to-use ('call it first'), explicit when-NOT-to-use ('Do NOT call log10x_doctor or log10x_login_status as a pre-flight'), and names the alternative flow when sign-in is needed (chain through log10x_signin_start then re-invoke). It even explains why the exclusion exists (doctor warnings confuse users). Nothing is left to inference.

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