Install
Requires Node.js 20+. Package: log10x-mcp on npm. To add the server to your client (Claude, Cursor, VS Code, Codex, and more), use Get Started. This page covers what comes after the add: credentials, optional log-analyzer access, multiple environments, and helping your AI pick the tools.
What you'll see after install
The MCP registers the tools your environment supports. With a key (or after signing in) you get the full set; with no key it boots read-only against the public demo so you can try it immediately. Run log10x_doctor to see what it resolved. Tools return structured JSON; pass view: "markdown" on any tool for a human-readable rendering.
Credentials
Three ways to authenticate, in order of convenience:
- GitHub sign-in (recommended): install with no
LOG10X_API_KEY, then ask the LLM to "sign in to Log10x".log10x_signinruns the GitHub Device Flow, mints a key, and saves it to~/.log10x/credentials(mode 0600), shared across every MCP host on the machine. -
Paste a key: copy it from console.log10x.com → Profile → API Settings and add it to the server's
envblock: -
Demo mode: install with no key and skip sign-in, the MCP boots read-only against the public demo so you can try the tools without an account.
Your environments are autodiscovered from your account in all three cases, with no environment ID to configure.
Optional log-analyzer access
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 ready-to-run bash) and POC submit. When omitted, the affected tools fall back to copy-paste 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.
Multiple environments
No client-side multi-credential setup needed. Two patterns:
- Same account owns multiple envs (prod / staging / dev): the MCP autodiscovers every env your account can reach. 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 backend supports per-env permission sharing (OWNER / WRITE / READ). Have the env owner grant your account READ from the console; it then shows up for you 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.
Help your AI find the tools
Even with the MCP installed, AI clients sometimes miss it for natural-language questions ("am I logged in?" → a which log10x shell probe instead of log10x_login_status). The tools are available but not always selected. A project rule nudges 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`
- "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:
CLAUDE.md (workspace root). Auto-read into every session and cascades from subdirectories. Append the snippet to whatever is already there, don't replace it.
No project-rule mechanism. Claude Desktop relies entirely on the tool descriptions in the MCP manifest, which are tuned for natural-language phrasings. If a specific phrasing keeps missing, open an issue.
.cursor/rules/log10x.mdc (workspace root). Wrap the snippet with frontmatter so the rule lands in every chat:
.windsurfrules (workspace root). Plain text, no frontmatter.
.github/copilot-instructions.md. Auto-applied for chats opened against this repo.
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 testing this fixed the most common discovery miss (status / login / "is it installed?" framings) across all clients.