Log10x MCP

Show pipeline savings: the bytes the Receiver keeps out of the SIEM (filtering and compact) and the bytes the Retriever indexed in the customer's bucket (priced at the SIEM rate, less storage, less what was streamed back), 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 measured volumes, prices + gates for that destination at list rates, and stamps siem_actual vs siem_lens in the envelope.

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

Conversational wizard that configures a scheduled cost-reduction tick (`tenx-recur`): each run clones the policy repo, recomputes the plan and pushes the changes. Walks the user through seven decisions: target services, savings target (%), tick schedule, scheduler runtime, gitops config repo, exception services, and final confirm, then emits two ready-to-commit artifacts: `policy.yaml` (the declarative policy the tick CLI consumes) and a scheduler manifest (Kubernetes CronJob YAML, GitHub Actions workflow, or crontab entry + wrapper script depending on the chosen scheduler). Each call merges the latest answer into the wizard session and either asks the next missing question or emits the artifacts once all answers are present. Re-invoke with the same `session_id` on every subsequent turn; sessions live 30 minutes. To skip interactive Q&A, supply all fields (`target_services`, `target_percent`, `schedule`, `scheduler`, `config_plane`, `confirm: true`) in a single call. Optional overrides: `exceptions` (services never touched), `min_delta_pp` (minimum savings delta before committing a new CSV, default 2pp), `env_id`, `namespace`, `secret_name`. Apply instructions for the chosen scheduler are in `data.apply_instructions`. After the first tick runs, call `log10x_commitment_report` to verify realized savings. REQUIRES nothing deployed to ASK: it renders manifests from the user's answers and writes to no account. The emitted tick needs a scheduler runtime (k8s CronJob, GitHub Actions, crontab, EventBridge, Container Apps job) and a policy repo or S3 prefix that the customer controls before it runs.

Generate the customer-applied SIEM-side connector config (Datadog Forwarder Lambda, or the Splunk Add-on for AWS SQS-based S3 input) that makes a SIEM pull log10x's offload output from the customer's own S3 bucket. Call this when the user has offloaded a pattern's data to S3 (the offload action / a log10x_offload_add destination) and asks how to get Datadog or Splunk to ingest it, e.g. 'ship my offload bucket to Splunk' or 'wire Datadog to read these logs'. The MCP does not push offloaded events into a SIEM: the offload lands NDJSON in the customer's bucket, and this tool emits the pull-side connector the SIEM reads it with. Args: siem (required: datadog / splunk / both), bucket (required: the offload bucket), account_id (required), region (default us-east-1), prefix (optional, default app/), plus per-SIEM options (datadog_forwarder_arn, sqs_queue_name, sourcetype, index). Returns, per target: the discovery model, ordered setup steps, paste-ready terraform (an SNS fan-out plus IAM, and for Splunk the SQS queue and the S3-to-SNS-to-SQS notification), the SIEM-native config (the Splunk inputs.conf aws_sqs_based_s3 stanza), and verified caveats. Recipes are matched to log10x's offload output (uncompressed NDJSON, one event per line, Hive-partitioned keys) and encode the key gotcha: the offload bucket usually already notifies the 10x indexer's SQS, and S3 allows only one notification config per overlapping prefix, so both recipes fan out via SNS rather than a second raw bucket notification. Caveats: Datadog is logs-only (use log10x_backfill_metric for per-pattern metrics), and the Splunk SQS-based input collects only objects created after setup (backfill older data with a Generic S3 input). Read-only: it generates config and does not create AWS resources or mutate any env document.

Step 2 of the Log10x sign-in chain. Two mutually-exclusive paths controlled by which argument is passed. (a) **`{ device_code: "<...>" }`**: finishes the browser flow that `log10x_signin_start` began. The model should call this AUTOMATICALLY right after `log10x_signin_start` returns, passing back the opaque `device_code` from that response unchanged. Polls Auth0's `/oauth/token` until the user confirms the device authorization in their browser, then exchanges the Auth0 access token for a long-lived Log10x API key. (b) **`{ api_key: "<key>" }`**: pasted-key path, no browser. Validates the key against `/api/v1/user` and saves it. **Pass exactly one of `device_code` or `api_key`**; both or neither is rejected with a clear error. Either path writes the resolved API key to `~/.log10x/credentials` (mode 0600), hot-reloads the MCP's env list in-process, and (if `LOG10X_API_KEY` is set in the host config and would override the new file) clears that env var in-process and tells the user to remove it from their host config to make the change permanent.

Step 1 of the Log10x browser sign-in chain. **Call this for any of these phrasings**: 'sign me up for Log10x', 'create a Log10x account', 'log me in to Log10x', 'set up my Log10x account', 'switch from demo to my own data'. Requests an Auth0 device code, opens the user's browser to auth.log10x.com with the user_code pre-embedded, and returns IMMEDIATELY (no polling). Response carries `user_code`, `verification_uri_complete`, and the opaque `device_code`. **What the model MUST do after this returns**: (1) show the user the `user_code` and `verification_uri_complete` so they can verify the code in their browser matches, then (2) AUTOMATICALLY call `log10x_signin_complete` with `{ device_code: "<the device_code from this response>" }` as the next tool call. The user does NOT need to ask for that second step. **For pasted-key sign-in instead of browser**: skip this tool and call `log10x_signin_complete` directly with `{ api_key: "<key>" }`.

Wipe the persistent credentials file at `~/.log10x/credentials` and reload envs so subsequent calls fall back to demo mode (or whichever lower-priority configuration source picks up). **Call this for**: "sign me out of Log10x", "log out", "remove my Log10x credentials", "stop using my Log10x account", "go back to demo mode". Idempotent: running it without saved credentials is a no-op. Does NOT revoke the API key on the BE; the user must do that from console.log10x.com → Profile → API Settings if they want to invalidate the key everywhere (mirrors `gh auth logout` and `aws sso logout`). If the user has `LOG10X_API_KEY` set in their MCP host config, that env var will still be active after sign-out: the tool result will flag this so the LLM can tell the user to also unset it and restart.

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 fields the agent follows: `must_render_verbatim` (markdown to show the user as is, without summarising), `must_ask_user` (a numbered question to ask before any follow-up tool call) and `forbidden_next_actions` (tools not to 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 measured volumes, prices + gates for that destination at list rates, and stamps siem_actual vs siem_lens in the envelope.

Rank log patterns by byte volume and cost per pattern (bytes priced at the destination's $/GB rate when one is set), over a time range, for one service or all. Each row carries a trajectory badge (NEW, ACUTE, GROWING, STABLE or SHRINKING) read against 7, 14 and 21 day baselines. Use for "what is expensive right now", "what are the noisy patterns in <service> this hour", "give me a snapshot of my loudest events". For "what changed this week" or "did the deploy add cost", use `log10x_whats_changing`, which ranks patterns by change against a `comparison_window` baseline. Can be scoped by service label. `timeRange` accepts free-form `<n><m|h|d>` durations (e.g., `48h`, `3d`, `15m`): there's no enum snap. Pass `include` to choose which cohort to rank: `kept` (default, what the Receiver forwarded), `dropped` (the offloaded / overflow cohort alone), or `both` (total ingest pre-receiver). Use `dropped` for "what is the receiver throwing away" and `both` for an apples-to-apples pre/post comparison. Accepts siem_lens (what-if destination): keeps the measured volumes, prices + gates for that destination at list rates, and stamps siem_actual vs siem_lens in the envelope. REQUIRES Reporter-tier metrics. Before anything is deployed, the POC tools answer the same question from the user's own logs.

Patterns ranked by delta vs a baseline window: the "what grew (or shrank) the most since X" question. Distinct from `log10x_top_patterns` which ranks by current cost; this tool ranks by delta and applies gates (`min_delta_usd`, `min_delta_contribution_pct`) that drop noise-level changes. `comparison_window: "auto"` (default) averages three offsets (1×, 2×, 3× the timeRange) for noise smoothing; specific offsets like `"7d"` compare to a single anchor, e.g. `{timeRange: "1d", comparison_window: "1d"}` is today vs yesterday (deploy-delta), `{timeRange: "7d", comparison_window: "7d"}` is this week vs last week. Brand-new patterns (no baseline samples) are EXCLUDED: they go to `log10x_whats_new` for clean separation of stories. Use for "what grew most this week", "which patterns regressed after the deploy", "what's driving cost up since yesterday". Returns patterns with per-row delta_usd, baseline_usd, current_usd, delta_pct, and a flag for whether each row crossed the contribution gate.

Patterns whose first_seen timestamp falls inside a recency window: the "what showed up recently" question. Distinct from `log10x_top_patterns` (current cost ranking) and `log10x_whats_changing` (delta vs baseline). New patterns have no baseline, so delta math is meaningless; this tool exists so they get a clean home and don't pollute the changing-vs-baseline surface. Implementation: queries bytes_per_pattern in the current `timeRange` window to find candidate hashes, then for each hash queries the 30-day history to find the earliest non-zero datapoint via `fetchFirstSeenBatch`. A pattern is "new" when its first_seen timestamp is younger than `first_seen_within` (default `1d`). Default sort: by first_seen recency descending (most recent first). Use `first_seen_within: "1h"` for incident triage, `"1d"` for daily-deploy review, `"7d"+` for weekly observability hygiene. Returns patterns with first_seen, age, cost_now_usd, bytes_now, events_now, and the service + severity attribution. An engine upgrade that changes the naming rules renames the patterns it affects once, so the first windows after it list those patterns here as new, first seen from the upgrade on.