Install

Requires Node.js 20+. Package: log10x-mcp on npm.

Three ways to get credentials, in order of convenience:

1. GitHub sign-in (recommended), install with no LOG10X_API_KEY set, then ask the LLM to "sign in to Log10x". log10x_signin runs the GitHub Device Flow, mints an API key, and saves it to ~/.log10x/credentials (mode 0600), works across every MCP host on the same machine.
2. Paste a key, copy your key from console.log10x.com → Profile → API Settings and set LOG10X_API_KEY in the host config below.
3. Demo mode, install with no key set and skip sign-in: the MCP boots read-only against the public Log10x demo env so you can try the tools without an account.

The env list is autodiscovered from GET /api/v1/user in all three cases, no environment ID to configure.

Engine compatibility

The MCP shells out to the local tenx engine for privacy-mode templater tools (Triage, Catalog). Match the engine to the MCP version:

MCP version	tenx engine	Notes
1.8.13+	1.0.22+ (recommended)	Triage with privacy_mode: true invokes tenx @apps/mcp over stdin/stdout, keeping events off disk. Requires the apps/mcp runtime shipped in the engine release, first available in 1.0.22.
1.8.x	1.0.21 (with overrides)	Earlier engines run the MCP only with TENX_CONFIG and TENX_MODULES pointed at local clones of log-10x/config and log-10x/modules at the apps/mcp branches.

brew upgrade log10x pulls the latest released engine. OS-specific installers live on the install index.

Config

{
  "mcpServers": {
    "log10x": {
      "command": "npx",
      "args": ["-y", "log10x-mcp"],
      "env": {
        "LOG10X_API_KEY": "your-api-key"
      }
    }
  }
}

Omit the env block entirely to boot in demo mode and use log10x_signin to mint a key in-flight.

Optional log analyzer credentials

Setting log analyzer credentials in the MCP host's env block unlocks executed-mode behavior in tools that scan or analyze your log analyzer directly, most prominently Dependency check (returns the actual list of dashboards / alerts referencing a pattern instead of paste-ready bash) and POC submit. When omitted, the affected tools fall back to paste-ready output. All scans are read-only.

Vendor	Env vars
Splunk	SPLUNK_HOST + SPLUNK_TOKEN (basic-auth and ~/.splunkrc also accepted; SPLUNK_WEB_URL overrides the derived :8000 web URL)
Datadog	DD_API_KEY + DD_APP_KEY (DATADOG_* aliases work; DD_SITE for site routing)
AWS / CloudWatch	Standard AWS credential chain (AWS_PROFILE, IAM role, etc.)
Elasticsearch (via Kibana)	KIBANA_URL + KIBANA_API_KEY (or ELASTIC_API_KEY)

vendor and destination arguments are auto-detected when exactly one set of log analyzer creds is present. With multiple, the tool returns a structured "ambiguous" response listing the candidates.

Retriever tunables

Env var	Default	Effect
LOG10X_RETRIEVER_SERIES_USE_SUMMARIES	off	When set, Series and other rollup-shaped tools route through the summaries pathway (qrs/) instead of events (qr/). Counts stay exact across all matched events at any window size. See Summaries for the trade-off.
LOG10X_RETRIEVER_QUERY_PATH	/streamer/query	Override the engine REST path for POST /streamer/query. Set when fronting the Retriever query endpoint behind a different route.

Clients

Client	Config location	Setup
Claude Desktop	macOS: ~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\	Paste the config into mcpServers, restart Claude Desktop
Claude Code	CLI, no file edit	claude mcp add --transport stdio --env LOG10X_API_KEY=KEY log10x -- npx -y log10x-mcp (drop --env LOG10X_API_KEY=KEY to boot in demo mode and run log10x_signin)
Cursor / Windsurf / other	Varies by client	Paste the config into mcpServers

Help your AI find the tools

Even with the MCP installed, AI clients sometimes miss it for natural-language questions ("am I logged in?" → which log10x shell probe instead of log10x_login_status). The MCP tools are available but not always selected. Project rules nudge the agent toward MCP-first tool selection. Drop a rule file containing this text:

The log10x MCP server is installed in this workspace. For any log10x
question, login state, log costs, patterns, services, savings,
investigations, retriever queries, exclusion configs, install advice , 
call the log10x MCP tools BEFORE shelling out to a CLI or probing env
vars. There is no `log10x` shell binary; the MCP IS the surface.

Common phrasings → tool:

- "login status", "am I logged in", "list my envs" → `log10x_login_status`
- "sign in", "log me in", "create account" → `log10x_signin`
- "what's expensive right now", "what changed week-over-week", "cost drivers" → `log10x_top_patterns` (pass `comparison_window` for the delta column)
- "what is this log line" → `log10x_event_lookup`
- "triage these events" → `log10x_resolve_batch`
- "investigate", "why is X spiking" → `log10x_investigate`
- "drop / mute this pattern" → `log10x_pattern_mitigate`
- "anything depend on this pattern" → `log10x_dependency_check`
- "health check", "is this set up right" → `log10x_doctor`

Each tool's full description and trigger phrases are in its MCP schema , 
read those before declining a request as "no log10x command available."

Where to put it, by client:

Client	Rule file	Notes
Cursor	.cursor/rules/log10x.mdc (workspace)	Wrap with frontmatter ---\ndescription: Use log10x MCP for log10x questions\nalwaysApply: true\n--- so the rule lands in every chat.
Claude Code	CLAUDE.md (workspace root)	Auto-read into every session; cascades from subdirs. Append the snippet to whatever's already there, don't replace.
Windsurf	.windsurfrules (workspace root)	Plain text, no frontmatter.
Copilot Chat	.github/copilot-instructions.md	Auto-applied for chats opened against this repo.
Claude Desktop	(none)	No project-rule mechanism, Claude Desktop relies entirely on the tool descriptions in the MCP manifest. The descriptions are tuned for natural-language phrasings, but if a specific phrasing keeps missing, open an issue so we can fold it in.

Why this works: the rule lands in the system prompt every turn, raising the agent's prior on "use the MCP for log10x topics" and short-circuiting the default shell-exploration heuristic. In our testing, this fixed the most common discovery miss (status / login / "is it installed?" framings) across all four clients.

Multiple Environments

No client-side multi-credential setup needed. Two patterns:

• Same account owns multiple envs (prod / staging / dev), the MCP autodiscovers all envs your account can reach via GET /api/v1/user. Pass environment: "<nickname>" on any tool call, or just say "check staging costs" and the LLM routes there. The chosen env sticks for follow-up calls until you switch again.
• Multiple accounts (e.g., a consultant accessing customer envs), the Log10x backend supports per-env permission sharing (OWNER / WRITE / READ). Have the env owner grant your account READ on their env from the console; it then shows up in your /api/v1/user response automatically. If you genuinely need parallel access from distinct API keys, register one MCP server per account in your host config with distinct server names.

Next: Test