Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Pipeline savings

log10x_savings

Read-onlyIdempotent

See how much log bytes and dollars your pipeline saves: reports percent removed by receiver filtering/compaction and retriever indexing, with dollar ROI when an ingest $/GB rate is set.

Instructions

Show pipeline savings — what percent of bytes the receiver (filtering + compaction) and retriever (indexing) are removing, with a dollar overlay when an analyzer $/GB rate is set (account profile list price, or per-call effective_ingest_per_gb override). Without a rate, the headline is percent-and-bytes only — never a fabricated $1/GB number. Use for "how much are we saving", "pipeline ROI", or "what is the Log10x stack worth financially". 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`view`	No	Output format. Always "summary" — the typed envelope (data.totals, data.edge, data.retriever, data.run_rate). Field retained for backward-compat.	summary
`siem_lens`	No	What-if destination lens: price the SAME real volumes at this destination's list rates instead of the connected pipeline's. Dollars switch to the lens list price (env-configured rates never leak across destinations); the envelope stamps siem_actual vs siem_lens. Volumes/patterns are unaffected.
`timeRange`	No	Time range. '24h' and '1d' are equivalent.	7d
`environment`	No	Environment nickname
`storageCost`	No	S3 storage cost in $/GB/month. Defaults to $0.023 (S3 Standard).
`analyzerCost`	No	DEPRECATED alias for effective_ingest_per_gb. stack ingestion cost in $/GB.
`effective_ingest_per_gb`	No	Customer-supplied stack ingestion cost in $/GB. When provided, rate_source=customer_supplied and dollars are populated. When omitted and no profile rate is available, rate_source=unset and the headline reports percent + bytes only (no dollars).

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

Behavior4/5

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

Annotations already cover read-only/idempotent/open-world, but the description adds real behavioral policy: without a rate it reports percent-and-bytes only and 'never a fabricated $1/GB number', and siem_lens switches pricing to list rates and stamps siem_actual vs siem_lens. This goes meaningfully beyond the annotations, though it doesn't cover latency, permissions, or rate limits.

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 definition, then the dollar-overlay condition, then use cases, then the siem_lens note. It is a dense single paragraph that borders on long, and the closing siem_lens sentence partially duplicates the schema's siem_lens description.

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, and it covers the key conditional behavior an agent needs (rate source determines whether dollars appear). Nothing essential for correct invocation is 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 semantics the schema lacks: what siem_lens does to volumes vs. pricing, and the rate_source fallback behavior tied to effective_ingest_per_gb. The output-shaping role of view/timeRange is largely left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Show pipeline savings') and breaks down the computation ('what percent of bytes the receiver (filtering + compaction) and retriever (indexing) are removing'), which is genuinely distinguishing. It does not, however, name or contrast against the close sibling log10x_estimate_savings, so the agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Concrete trigger phrases are given ('how much are we saving', 'pipeline ROI', 'what is the Log10x stack worth financially'), and the rate-dependent condition for when dollars appear is explained. No explicit when-not guidance or named alternative tools, so it stops short of a 5.

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

Deploy Server