Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Services

log10x_services

Read-onlyIdempotent

Lists every service the Log10x pipeline monitors, ranked by byte volume and cost, with per-service shares and pass/offload/compact/drop totals so you can target log reduction.

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.] List every service the Log10x pipeline is watching, ranked by byte volume (with cost overlay when $/GB is set) plus per-service share of total AND the four action-axis columns (bytes_passed / bytes_offloaded / bytes_compacted / bytes_dropped) derived by joining routeState="drop" events against the cap-CSV. Pass exception_services to mark customer-flagged services as current_mode=pass: their next_action points at log10x_pattern_mitigate instead of log10x_configure_engine.

Input Schema

Name	Required	Description	Default
`view`	No	Output format. Always "summary": the typed envelope (data.services[], data.totals). Field retained for backward-compat.	summary
`siem_lens`	No	What-if destination lens: price the per-service $/mo columns at this destination's default rates instead of the connected pipeline's (env-configured rates never cross destinations). Volumes/patterns are unaffected; the envelope stamps siem_actual vs siem_lens.
`timeRange`	No	Time range. Sub-day values available for incident-window service ranking. '24h' and '1d' are equivalent.	7d
`environment`	No	Environment nickname
`analyzerCost`	No	SIEM ingestion cost in $/GB
`monthly_volume_gb`	No	What-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 real patterns.
`exception_services`	No	Customer-flagged services that must stay in the SIEM with full retention (audit / regulatory / executive). Per row, marks current_mode="pass" and points next_action at pattern_mitigate instead of the configure_engine bulk path.

Output 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.

Changed2 schema fields changedv1.30.8Oct 15, 2026

changedInput schema / properties / siem_lens / description

Previous value: -"What-if destination lens: price the per-service $/mo columns at this destination's list rates instead of the connected pipeline's (env-configured rates never cross destinations). Volumes/patterns are unaffected; the envelope stamps siem_actual vs siem_lens."New value: +"What-if destination lens: price the per-service $/mo columns at this destination's default rates instead of the connected pipeline's (env-configured rates never cross destinations). Volumes/patterns are unaffected; the envelope stamps siem_actual vs siem_lens."

changedInput schema / properties / view / description

Previous value: -"Output format. Always \"summary\" — the typed envelope (data.services[], data.totals). Field retained for backward-compat."New value: +"Output format. Always \"summary\": the typed envelope (data.services[], data.totals). Field retained for backward-compat."

First observedv1.30.7Sep 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, yet the description goes further: it discloses that action-axis columns are derived by joining routeState="drop" events against the cap-CSV, that the envelope stamps siem_actual vs siem_lens, and that projection mode stamps volume_actual_gb vs volume_projected_gb plus a scale factor. This is rich internal behavior not recoverable from annotations.

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?

The routing directive is front-loaded ahead of the functional description, and nearly every sentence carries distinct information. It is dense and somewhat run-on, but not padded with 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?

With an output schema present, the description needn't explain return values, yet it usefully names the resulting columns and envelope stamps. It covers the what-if/projection modes and the exception path; only pagination/limit behavior is unaddressed, a minor gap.

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%, so the schema already documents all seven parameters, and the description's exception_services explanation largely restates the schema's own wording. Baseline 3 is appropriate since the description adds only marginal semantics beyond what the structured fields provide.

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 resource — 'List every service the Log10x pipeline is watching, ranked by byte volume' — and enumerates the exact output columns (per-service share plus the four action-axis columns). An agent can distinguish it from siblings like log10x_top_patterns or log10x_savings without opening any schema.

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?

Explicitly routes the agent to log10x_start when this is the first cost question of the session, and explains that when exception_services is supplied the downstream next_action points at log10x_pattern_mitigate rather than log10x_configure_engine. It gives clear context but does not contrast this tool against the other listing siblings (e.g., top_patterns) in the negative case.

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

Deploy Server