Skip to main content
Glama
log-10x

Log10x MCP Server

Official

POC from local logs (kubectl)

log10x_poc_from_local
Read-only

Run a log-cost-optimization proof-of-concept using local logs when no SIEM credentials are available. Generates a report with sample composition, pricing matrix, and top patterns.

Instructions

Run a log-cost-optimization POC entirely from local log sources: pass path for one log file (wrapper-normalized) or paths for files, directories and globs; kubectl samples pod logs; docker and journald to follow. No log-analyzer credentials required. Use when the prospect has no SIEM connection or has not yet shared API keys. Returns a synchronous markdown report with: (a) sample composition table, top-N pods by byte volume; the prospect must confirm the sample looks like their production mix, (b) industry-pricing matrix, projected savings at Datadog / Splunk / CloudWatch / Sumo / Elastic / OpenSearch list prices, NOT a prediction of any specific bill, (c) top patterns in the kubectl-sourced sample. For native exclusion configs, paste-ready Receiver YAML, and the full 9-section report tied to a specific log analyzer's GB-billed volume, run log10x_poc_from_siem_submit once credentials are available. No automatic fallthrough: this tool is invoked explicitly. If log10x_poc_from_siem_submit failed on missing credentials, the calling LLM should ask the user before re-invoking with this tool: local-source framing differs from SIEM-attached framing and silent fallthrough would be a bait-and-switch. REQUIRES a local engine: the tenx binary on PATH, or Docker with LOG10X_TENX_MODE=docker. No log-analyzer credentials and no deployment are needed, but without an engine this returns an error rather than a report. Pass target_percent_reduction as a whole-number percent (e.g. 40 for 40%) to get a feasibility verdict against that target. Two modes, and the agent should name whichever the user's phrasing invites. Run normally, this tool reads local files but the server around it still has network. Run inside the FENCED profile (TENX_AIRGAPPED=true, --network none, the log10x/poc image) it is the same analysis with no network at all, and its output carries its own docker inspect proof. log10x_emit_sample_plan produces the sample for that mode from the user's own analyzer. Offer it; do not ask which one first.

Input Schema

NameRequiredDescriptionDefault
pathNoOne local log file to analyse (source=`file`). Wrapped JSONL is normalized so the engine patterns payloads, not wrappers. For many files or globs use `paths` instead.
siemNoThe destination SIEM, used for the report header chip and command selection. When absent the analysis assumes CloudWatch and the report labels the assumption.
pathsNoRequired for `source: file`: files, directories, or glob patterns (`*`, `**`, `?`) to sample, e.g. `["/var/log/app/*.log", "./bundle/**"]`. A directory is read one level deep; use `dir/**` for the tree.
sourceNoWhere to pull log lines from. `kubectl` samples pod logs; `file` samples local logs: pass `paths` (files, directories, globs) or `path` (one file; fluentd/k8s/docker-wrapped JSONL is detected and normalized before the engine sees it). `docker` and `journald` are follow-up work.kubectl
windowNoHow far back to read per pod (`source: kubectl`, default `1h`). For `source: file`, the time span the files cover: read from the first and last record timestamps when the records carry them, and from `window` when they do not. With neither, a file run refuses rather than assume a span. Accepts `30m`, `10h`, `7d`, etc.
max_podsNoCap on number of pods sampled. Default 20.
workloadNoForwarder workload name (daemonset/deployment) for the apply commands. Not guessed when absent.
forwarderNoForwarder in the pipeline (fluentd, fluent-bit, filebeat, logstash, otel-collector, vector, hec). Used to pick verified apply/undo commands. Not guessed when absent: the report says commands are unavailable.
namespaceNoKubernetes namespace to sample from (`source: kubectl` only). Pass `*` to sample across all namespaces. Default `default`.default
allow_lossyNoPermit sample/drop (lossy) to close a keep-everything shortfall. Default false: the plan stops at the keep-everything ceiling and reports the gap. Only set after the user explicitly chooses loss.
pin_patternsNoAdvanced: most customers will not need this. Map of pattern_hash to action for rare per-pattern overrides within a pod / source. Applied AFTER pin_services.
pin_servicesNoPrimary per-pod/source override surface. Map of pod / source name to action. Pins are applied AFTER the destination default and AFTER exception_services. Feasibility reruns with the pins; max_achievable shifts and reason cites the pins.
fleet_defaultNoSet the fleet default from this capture: the limit for every service the plan gives no row, the largest statement the plan keeps per node times the headroom. The report states it in lines a day, and `fleet_default.cap_bytes_per_window_per_node` in the result is the value `log10x_advise_install` writes. On Datadog, the dependency check also lists the log monitors and log-based metrics of the services it covers, error monitors included.
per_pod_limitNoCap on log lines pulled per pod. Default 5000.
budget_gb_monthlyNoVOLUME BUDGET: keep projected monthly ingest at or under this many GB/mo. BYTE accounting: tier_down keeps every byte and is excluded from the ladder for this target. Sample scaled to a 30-day month before solving. Mutually exclusive with target_percent_reduction and budget_usd_monthly.
budget_usd_monthlyNoDOLLAR BUDGET: keep the projected monthly bill on the assumed SIEM at or under this $/mo. The sample is scaled to a 30-day month (kubectl window, or the file span) before solving, so the budget and the bill share a denominator. Mutually exclusive with target_percent_reduction and budget_gb_monthly.
check_dependenciesNoDatadog only, default true: before the plan moves statements off Standard, read the account's log monitors and log-based metrics (read-only GETs, needs DD_API_KEY + DD_APP_KEY in the session) and print beside each service line the ones whose query reads its moved lines. Set false to skip the read.
exception_servicesNoServices / pods flagged by the customer to stay in the log analyzer with full retention (action=pass). Their bytes are subtracted from the achievable reduction pool used for the feasibility verdict. Matched case-insensitively against the pod / source name.
report_annotationsNoOptional one-sentence annotations keyed by evidence statement identifier, rendered under the matching action. Hard cap 140 chars each; over-cap or unknown-hash input refuses the render (nothing is truncated).
retriever_installedNoWhether the prospect will install the S3 retriever. Gates the offload rung of the plan ladder: without it offloaded events would be unreachable, so the plan stops at the in-SIEM levers and the gap names "install the retriever" as the keep-everything remedy. Set from conversation.
record_overhead_bytesNoBytes of forwarder metadata per record, for a capture that carries the log text only (a kubectl sample or plain lines). The Receiver counts each record as the forwarder sends it, metadata included, so the caps add this to every line. Default 760, the median of a Fluent Bit kubernetes record on an EKS capture. A file of the forwarder's own JSON records is measured instead.
target_percent_reductionNoCustomer-specified target reduction percent. If absent, POC produces a recommendation-only output. If present, POC produces a feasibility verdict + a pre-deploy commitment artifact stub the agent can surface alongside the per-pod savings matrix. The cap CSV is attached by a later change.

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. Changed10 schema fields changedv1.30.8
    • changedInput schema / properties / budget_usd_monthly / description
      Previous value: -"DOLLAR BUDGET: keep the projected monthly bill on the assumed SIEM at or under this $/mo. The sample is scaled to a 30-day month (kubectl window, or file timestamp span) before solving, so the budget and the bill share a denominator. Mutually exclusive with target_percent_reduction and budget_gb_monthly."New value: +"DOLLAR BUDGET: keep the projected monthly bill on the assumed SIEM at or under this $/mo. The sample is scaled to a 30-day month (kubectl window, or the file span) before solving, so the budget and the bill share a denominator. Mutually exclusive with target_percent_reduction and budget_gb_monthly."
    • addedInput schema / properties / check_dependencies
      Added value: +{
      +  "description": "Datadog only, default true: before the plan moves statements off Standard, read the account's log monitors and log-based metrics (read-only GETs, needs DD_API_KEY + DD_APP_KEY in the session) and print beside each service line the ones whose query reads its moved lines. Set false to skip the read.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / fleet_default
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Set the fleet default from this capture: the limit for every service the plan gives no row, the largest statement the plan keeps per node times the headroom. The report states it in lines a day, and `fleet_default.cap_bytes_per_window_per_node` in the result is the value `log10x_advise_install` writes. On Datadog, the dependency check also lists the log monitors and log-based metrics of the services it covers, error monitors included.",
      +  "properties": {
      +    "action": {
      +      "description": "Where a statement above the limit goes: `tier_down` (Flex on Datadog, the default) or `offload` (S3).",
      +      "enum": [
      +        "tier_down",
      +        "offload"
      +      ],
      +      "type": "string"
      +    },
      +    "error_floor": {
      +      "description": "Share of ERROR and CRITICAL lines above the limit kept in Standard. Default 0.5 with offload, 0 with tier_down.",
      +      "maximum": 1,
      +      "minimum": 0,
      +      "type": "number"
      +    },
      +    "headroom": {
      +      "description": "Multiplier on the largest kept per-node cell of the capture. Default 2.",
      +      "maximum": 10,
      +      "minimum": 1,
      +      "type": "number"
      +    }
      +  },
      +  "type": "object"
      +}
    • changedInput schema / properties / forwarder / description
      Previous value: -"Forwarder in the pipeline (fluentd, fluent-bit, filebeat, logstash, otel-collector, vector, hec). Used to pick verified apply/undo commands. Not guessed when absent — the report says commands are unavailable."New value: +"Forwarder in the pipeline (fluentd, fluent-bit, filebeat, logstash, otel-collector, vector, hec). Used to pick verified apply/undo commands. Not guessed when absent: the report says commands are unavailable."
    • changedInput schema / properties / pin_patterns / description
      Previous value: -"Advanced — most customers will not need this. Map of pattern_hash to action for rare per-pattern overrides within a pod / source. Applied AFTER pin_services."New value: +"Advanced: most customers will not need this. Map of pattern_hash to action for rare per-pattern overrides within a pod / source. Applied AFTER pin_services."
    • addedInput schema / properties / record_overhead_bytes
      Added value: +{
      +  "description": "Bytes of forwarder metadata per record, for a capture that carries the log text only (a kubectl sample or plain lines). The Receiver counts each record as the forwarder sends it, metadata included, so the caps add this to every line. Default 760, the median of a Fluent Bit kubernetes record on an EKS capture. A file of the forwarder's own JSON records is measured instead.",
      +  "maximum": 100000,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / retriever_installed / description
      Previous value: -"Whether the prospect will install the S3 retriever. Gates the offload rung of the plan ladder: without it offloaded events would be unreachable, so the plan stops at the in-SIEM levers and the gap names \"install the retriever\" as the lossless remedy. Set from conversation."New value: +"Whether the prospect will install the S3 retriever. Gates the offload rung of the plan ladder: without it offloaded events would be unreachable, so the plan stops at the in-SIEM levers and the gap names \"install the retriever\" as the keep-everything remedy. Set from conversation."
    • changedInput schema / properties / source / description
      Previous value: -"Where to pull log lines from. `kubectl` samples pod logs; `file` samples local logs — pass `paths` (files, directories, globs) or `path` (one file; fluentd/k8s/docker-wrapped JSONL is detected and normalized before the engine sees it). `docker` and `journald` are follow-up work."New value: +"Where to pull log lines from. `kubectl` samples pod logs; `file` samples local logs: pass `paths` (files, directories, globs) or `path` (one file; fluentd/k8s/docker-wrapped JSONL is detected and normalized before the engine sees it). `docker` and `journald` are follow-up work."
    • removedInput schema / properties / window / default
      Removed value: -"1h"
    • changedInput schema / properties / window / description
      Previous value: -"How far back to read per pod (`source: kubectl`). For `source: file` this is the time span you declare the sampled file tails to cover — it drives the daily projection, so set it if you know it. Accepts `1h`, `24h`, etc. Default `1h`."New value: +"How far back to read per pod (`source: kubectl`, default `1h`). For `source: file`, the time span the files cover: read from the first and last record timestamps when the records carry them, and from `window` when they do not. With neither, a file run refuses rather than assume a span. Accepts `30m`, `10h`, `7d`, etc."
  2. First observedv1.30.7

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only give readOnly/openWorld/idempotent; the description adds the real operational burden: a local engine is REQUIRED (tenx on PATH or Docker with LOG10X_TENX_MODE=docker) and its absence returns an error rather than a report, no credentials or deployment are needed, and the fenced mode has no network and carries `docker inspect` proof. It also discloses that output is a synchronous markdown report with a specific three-part structure.

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 the required-engine caveat early; most sentences carry distinct operational facts (credentials, error behavior, fallthrough policy, two modes). It is dense and long for a single tool, with some repetition about credentials and engine requirements, but little is pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 22-parameter tool with nested objects, it covers prerequisites, error behavior, alternatives, mode selection, and the report's shape. An output schema exists so return values needn't be explained (though the description does anyway). Minor gap: it doesn't clarify engine-selection precedence or how conflicts among the mutually exclusive budget parameters surface.

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 every parameter is already documented inline, so the schema does the heavy lifting. The description restates the `path` vs `paths` distinction already in the schema and adds a small usage note for `target_percent_reduction` (whole-number percent, e.g. 40). Marginal value beyond the schema — baseline 3.

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+scope: 'Run a log-cost-optimization POC entirely from local log sources', and immediately distinguishes itself from the SIEM-attached sibling `log10x_poc_from_siem_submit`. An agent can tell which POC path applies without opening either 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 ('no SIEM connection or has not yet shared API keys'), names the alternative and the credentials condition that selects it, and even prescribes the no-fallthrough behavior (ask the user before switching from a failed `log10x_poc_from_siem_submit`). Covers both the regular and fenced/airgapped modes and names `log10x_emit_sample_plan` for the latter.

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