Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Log10x orientation

log10x_start

Read-onlyIdempotent

Orient cost, forensic, or install sessions by detecting tier and SIEM, returning compliance steps, journey phase, and a gated action menu.

Instructions

CALL THIS FIRST whenever the user asks any open-ended cost question, says save X%, asks where do I start, what should I do, how can you help — before any other tool. Detects the customer's tier (Dev CLI / Reporter / Receiver / Retriever) via three live probes (gateway auth, Reporter metric counts, Retriever resolution), detects the SIEM, and returns a structured orientation envelope with three compliance levers the agent MUST obey: must_render_verbatim (markdown to surface to the user as-is, no summarising), must_ask_user (a numbered question the agent MUST ask before any follow-up tool call), and forbidden_next_actions (tool names the agent MUST NOT call until the user has picked an option). Also returns a 5-phase journey (Visibility → Attribution → Mitigation → Forensic → Commitment) showing where the customer is, an action menu gated by available capabilities (compact_installable, tier_down_available, offload_ready, forensic_query_available), and the resolved tier. The tool is read-only, takes an optional intent_hint (cost / forensic / install / orient), and is safe to call on any boot state — including when no env is configured yet (skips gateway/Reporter probes and treats the customer as Dev CLI tier). 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
`siem_lens`	No	What-if destination lens: orient pricing/applicability for THIS destination while the pipeline keeps its actual one (the user's stack differs from the connected demo/env). Carry the same siem_lens onto cost_options / estimate_savings / top_patterns / savings calls that follow.
`intent_hint`	No	Optional hint at what brought the user here. `cost` = wants to cut/save bill; `forensic` = wants to read back the offloaded cohort from the overflow bucket; `install` = wants to deploy; `orient` = first-time session, open-ended. When omitted, the tool treats it as `orient`.
`session_state`	No	Optional caller hint at where the user is in the session. `fresh` (default when omitted) = first message of a new chat, emit the full orientation envelope. `midway` = the agent has already surfaced the orientation envelope this session and the user is mid-flow, emit a short "already oriented, proceeding" envelope. `returning` = treated as `fresh` because the menu / journey phase may have shifted since the last session.

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

Behavior5/5

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

Annotations only cover read-only/idempotent/open-world safety; the description goes far beyond, disclosing three live probes, tier detection, the compliance-lever envelope (must_render_verbatim, must_ask_user, forbidden_next_actions), the 5-phase journey, capability-gated menu, and safe-on-any-boot-state behavior including no-env handling.

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 directive is well front-loaded ('CALL THIS FIRST...') and every clause carries operational signal, but the single dense paragraph lumps many concepts together and would benefit from structuring. Slightly over-stuffed for one sentence.

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 a complex orientation tool with an output schema already covering return values, the description is complete: boot-state edge cases, tier branching, siem_lens what-if semantics, and session_state handling are all addressed.

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 each parameter already has a detailed enum description, so the schema does the heavy lifting. The description restates intent_hint and siem_lens behavior (including carrying siem_lens forward to cost_options/estimate_savings) but adds little the schema does not already say.

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 (orientation/first-call tool), its scope (open-ended cost questions, 'where do I start'), and explicitly positions itself before all siblings ('before any other tool'). The agent can identify it as the entry-point tool 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 Guidelines5/5

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

Gives explicit trigger conditions ('CALL THIS FIRST whenever the user asks any open-ended cost question, says save X%, asks where do I start'), sequencing relative to other tools, and even encodes when-not-to-proceed via forbidden_next_actions gating. 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.

Deploy Server