Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Estimate savings

log10x_estimate_savings
Read-onlyIdempotent

Estimate log cost savings by forecasting proposed plans or verifying realized reductions, with percent reduction and dollar overlay.

Instructions

[FRESH-SESSION ROUTING: if this is the user first cost question of the session, call log10x_start first instead — it returns the orientation menu the user needs before any per-tool action.] Two-mode savings estimator with percent-first reporting and a dollar overlay. forecast projects bytes_in -> bytes_out and percent reduction for a proposed plan; pass effective_ingest_per_gb (or rely on the account profile list-price rate) to overlay $/mo per pattern and in totals. verify counts realized savings from the engine routeState label over a window with cap-hit / drift / new-patterns / leakage attribution, leading with percent and adding the dollar overlay only when a rate is set. Without a rate, dollar fields are emitted as null (never as a fabricated $1/GB number); the envelope carries rate_source: list_price | customer_supplied | unset so callers can show how the overlay was derived. Accepts siem_lens (what-if destination): keeps the real volumes, prices + gates for that destination at list rates, and stamps siem_actual vs siem_lens in the envelope. REQUIRES Reporter-tier cost attribution (per-pattern bytes in the metrics backend). Before anything is deployed, use log10x_poc_from_local or log10x_poc_from_siem_submit instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoforecast: project savings of a proposed per-pattern policy (or a target_percent). verify: measure realized savings from a deployed policy by comparing baseline vs post-merge windows.forecast
serviceNoScope the target_percent greedy solver and coverage_pct to a single service. When present, only patterns from that service are candidates; coverage_of_env_pct and dollar totals reflect that service only. pattern_limit is ignored (all service patterns are returned). If omitted, runs across all services.
es_prunedNoElasticsearch only: are compactable fields excluded from _source? Default false — the unpruned ratio band is used.
siem_lensNoWhat-if destination lens (alias of `destination` with provenance stamping): price the projection for THIS destination while the pipeline keeps its actual one. Envelope stamps siem_actual vs siem_lens.
timeRangeNoforecast mode: alias for `observation_window` for consistency with other Log10x tools. If both are set, `observation_window` wins.
deploymentNoHow the customer RUNS the destination, which decides whether compaction is available at all: the expander is software they install (the l1es Elasticsearch/OpenSearch plugin, the 10x Splunk app), so a managed or serverless platform can carry compacted bytes but has nowhere to expand them. Set only from what the user actually said — absent means unknown, and an unknown deployment prices only the levers that hold either way. Irrelevant on destinations whose levers do not depend on it (Datadog, CloudWatch, Azure, Coralogix).
allow_lossyNoPermit the ladder solver to close a keep-everything shortfall with sample/drop (lossy, opt-in). Default false: the plan stops at the keep-everything ceiling and reports the gap instead of silently discarding events. Only set after the user explicitly chooses loss.
destinationNoDestination stack. Required for both modes (used to look up ingest $/GB + compact ratio band).
environmentNoEnvironment nickname; routes to the right metrics backend.
post_windowNoverify mode: PromQL range expression for the post-merge window, e.g. "7d".
commitment_idNoverify mode: when present, the verify output is shaped as a commitment delta (used by log10x_commitment_report).
contract_typeNoverify mode: shapes the dollar projection (committed vs on-demand renewal math).
pattern_limitNoforecast mode: maximum number of per_pattern rows returned. Default 50 when service is omitted; ignored (unlimited) when service is set. Totals and coverage_pct are always computed over the full solver result before slicing.
default_actionNoforecast mode, OPTIONAL: force one action onto every solver-selected pattern (a mode choice — "cut 50% via drop"). Hard constraint when present, subject to destination compatibility (compact is replaced by the destination canonical action when compact_mode=no-op). OMIT for the product default: the ladder solver picks the destination's keep-everything lever per pattern (compact -> tier_down -> offload-with-retriever), never lossy unless allow_lossy.
target_percentNoforecast mode: % volume reduction goal. Tool runs the same greedy solver as configure_engine on observed 30d bytes.
tier_down_planNoWhich tier_down plan to price when the action is tier_down. Matches the plan name (case-insensitive substring): omit for the destination default (e.g. Azure Basic Logs), or pass e.g. "auxiliary" to price the aggressive alternative (Azure Auxiliary Logs). No effect on destinations without an alternative tier.
baseline_windowNoverify mode: PromQL range expression for the pre-merge window, e.g. "7d", "168h".
proposed_configNoforecast mode: explicit per-pattern (action, optional cap) rows. Either this OR target_percent is required.
enforcement_modeNoforecast mode: when manual_report, reframes the headline as a potential-savings estimate under external enforcement rather than engine enforcement. Headline reads 'If you enforce externally: X savings potential. Enforcement choice is yours.' instead of the standard forecast headline.
retention_monthsNoRetention window for storage cost. Default 1 month.
budget_gb_monthlyNoforecast mode: VOLUME BUDGET — keep monthly ingest toward the destination at or under this many GB/mo. BYTE accounting: tier_down keeps every byte in the destination, so it cannot serve this target and is excluded from the ladder (compact only where it lands on the billed wire, then offload with the retriever, then lossy on allow_lossy). Mutually exclusive with target_percent, budget_usd_monthly, default_action, and proposed_config.
monthly_volume_gbNoWhat-if volume lens (forecast mode): model the environment at THIS monthly volume (decimal GB/month) instead of its measured volume. The real per-pattern shares and pattern mix are held fixed; only absolute bytes and dollars scale, by one uniform factor. Use it to project a prospect onto their own scale, or to forecast a real env after growth. Pairs with `siem_lens`. This is a PROJECTION: the envelope stamps volume_actual_gb vs volume_projected_gb and the scale factor, and the note points at the POC for the caller's real patterns.
budget_usd_monthlyNoforecast mode: DOLLAR BUDGET — keep the (service-scoped or whole) destination bill at or under this $/mo. The ladder solver derives the reduction: max(0, bill - budget). Idempotent: already under budget returns an empty plan with the headroom stated. Mutually exclusive with target_percent, budget_gb_monthly, default_action, and proposed_config.
check_dependenciesNoLadder-plan path only: scan the destination (read-only) for dashboards, alerts, and saved searches that reference the top planned message types, and attach the result as plan_dependencies. Runs only when credentials for the destination are present in the session environment; otherwise the plan carries a one-line note saying it was not checked. Set false to skip the scan for speed.
exception_servicesNoLadder-plan path only: services pinned at pass — their patterns stay in the bill but are never planned, exactly like protected severities. The SOC-owned or compliance-bound slice of the estate, stated as a hard exclusion. Case-insensitive.
include_referencedNoLadder-plan path only: message types LITERALLY referenced by a monitor, alert, saved search, or dashboard (found by the dependency scan) are EXCLUDED from the plan by default — they stay exactly as they are, and the plan re-solves around them. Pass true only after the user explicitly chooses to include them (the render shows what including them adds).
observation_windowNoforecast mode: PromQL range expression for the observation window the solver/projection runs over. Default `30d`. Accepts `1h`, `24h`, `7d`, `30d`, etc. Alias: `timeRange`.
unprotect_patternsNoLadder-plan path only: pattern hashes the user EXPLICITLY unpinned from the severity floor (a warn-level retry storm they chose to act on). Bypasses severity protection for the listed hashes only; hard exclusions still win. Set only after the user names the type and chooses this — never inferred. The render flags these rows with their severity.
retriever_installedNoWhether the S3 retriever is installed (or the user has agreed to install it). Gates the offload rung of the ladder solver: 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; log10x_advise_retriever is the install path.
effective_ingest_per_gbNoforecast and verify mode: override the destination list-price rate with the customer's contracted $/GB. When supplied, dollar projections use this rate and surface rate_source='customer_supplied'.

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?

Annotations only declare readOnly/idempotent/openWorld=false; the description adds substantial behavior beyond them: null dollar fields rather than fabricated rates, the rate_source enum (list_price | customer_supplied | unset), siem_actual vs siem_lens provenance stamping, volume_actual_gb vs volume_projected_gb scale-factor stamping, and the tier prerequisite. This is exactly the extra context an agent needs for correct invocation.

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 the session-routing caveat, then purpose, then mode details and prerequisites — a sound order. It is dense for a 30-parameter tool but some phrasing repeats (the dollar-overlay/null-rate point is made multiple times), so it is not maximally 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?

With an output schema present, return values need not be described, and the description instead covers what the schema cannot: mode semantics, the routing prerequisite, the tier requirement, unsafe-default behavior (allow_lossy opt-in, no fabricated dollar numbers), and envelope provenance fields. Complete for a tool of this complexity.

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 real meaning beyond the schema on the two modes, the effective_ingest_per_gb rate-override contract, siem_lens provenance, and the Reporter-tier prerequisite that gates the tool. It does not attempt to re-explain all 30 params, which is appropriate given the schema already does that.

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 ('Two-mode savings estimator with percent-first reporting and a dollar overlay') and then decomposes both modes precisely: forecast projects bytes_in -> bytes_out and percent reduction; verify counts realized savings over a window. It explicitly distinguishes itself from siblings by naming log10x_poc_from_local, log10x_poc_from_siem_submit, and log10x_start as the correct tools in other situations.

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/when-not routing: 'if this is the user first cost question of the session, call log10x_start first' and 'Before anything is deployed, use log10x_poc_from_local or log10x_poc_from_siem_submit instead.' It also states the precondition (REQUIRES Reporter-tier cost attribution) and the mode-selection rule (forecast for proposed policy, verify for deployed policy).

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