Splunk Intelligence MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Log verbosity | DEBUG |
| SPLUNK_URL | No | Splunk base URL (required for live queries) | |
| SPLUNK_USE_LLM | No | Set 'true' to enable standalone Ollama agent (requires uv sync --extra llm) | false |
| SPLUNK_AUTH_PATH | No | Cookie persist path | ~/.splunk/auth.json |
| SPLUNK_LLM_MODEL | No | Ollama model — only used when SPLUNK_USE_LLM=true | qwen2.5:14b |
| SPLUNK_COOKIE_NAME | No | Splunk session cookie name | splunkd_8089 |
| SPLUNK_SPIKE_WINDOW | No | Spike detection window (seconds) | 60 |
| SPLUNK_AGENT_MAX_ITER | No | ReAct loop cap — only used when SPLUNK_USE_LLM=true | 10 |
| SPLUNK_SPIKE_THRESHOLD | No | Events/window to trigger a spike | 10 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| splunk__investigate_startA | Start a Splunk investigation. Loads events, runs detectors, returns structured findings for Claude to reason over. Args: source: Path to a Splunk export file (JSON or CSV). Use this OR spl. spl: SPL query string for a live Splunk query. Requires SPLUNK_URL configured. earliest: Earliest time for live query (default: -24h). latest: Latest time for live query (default: now). repo_path: Optional path to the microservice source repo. When provided, the agent can call splunk__lsp_call_chain to trace error log sites back through the call graph. Leave empty to skip code cross-referencing. Returns JSON with run_id and findings dict. |
| splunk__submit_reportA | Submit your investigation report and follow-up SPL queries to the server. The server stores the report, executes the queries, builds new findings, and returns either next findings (status=continue) or completion (status=done). Args: run_id: The run_id from splunk__investigate_start. report: Your markdown investigation report including Confidence: High/Medium/Low. queries: List of follow-up SPL query strings. Each starts with a '-- area' comment line. Returns JSON with status=continue+findings or status=done+ui_url. |
| splunk__get_findingsB | Get current findings from the active investigation session. Use this to inspect the latest detector output mid-loop. |
| splunk__pauseC | Pause the investigation after the current iteration completes. |
| splunk__query_examplesA | Return example SPL queries from past investigations stored in splunk.db. Use this to ground follow-up queries in field names and patterns that have actually worked against this Splunk environment. Args: area: Filter by area label (e.g. "tls", "cert", "auth"). Empty = all areas. limit: Max number of examples to return (default 20). Returns JSON list of {area, spl, result_rows, run_id, iteration} sorted by most recent first. result_rows is the event count the query returned, or null if it was never executed. |
| splunk__lsp_call_chainA | Trace a function or symbol through the microservice call graph using LSP. Use this during the Reason step to find which code path produced a log error. Args: run_id: Active investigation run_id. symbol: Function or class name to look up (e.g. "validate_cert", "TLSHandler"). file_path: Optional absolute path to the file containing the symbol. Speeds up lookup. line: Optional 1-based line number of the symbol definition. direction: "callers" (who calls this?) or "callees" (what does this call?). Default: callers. depth: How many levels up/down to trace. Default: 3. Returns JSON with the call chain and file locations, or an error if repo_path was not provided at investigate_start or if the symbol cannot be resolved. |
| splunk__hintA | Inject an analyst hint into the investigation for the next iteration. The hint is included in the findings passed to the next reasoning step. Example: "focus on web-01 cert chain errors after 14:30 UTC" |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Tools are mostly distinct: investigate_start initiates, get_findings retrieves current findings, hint injects hints, lsp_call_chain traces code, pause halts, query_examples provides example queries, submit_report submits a report. There is slight overlap between get_findings and the findings returned by investigate_start, but descriptions clarify the different usage points.
All tools share the 'splunk__' prefix and use lowercase with underscores, but the verb-noun pattern is inconsistent: 'get_findings' (verb_noun), 'hint' (just verb), 'investigate_start' (verb_noun), 'lsp_call_chain' (noun_verb), 'pause' (verb), 'query_examples' (noun_verb), 'submit_report' (verb_noun). Some tools are single words, others have multiple parts, but overall readable.
Seven tools is a reasonable count for a focused investigation server. It covers the core workflow without being excessive. A few more could be added (e.g., listing past investigations), but the current count is appropriate.
The tool set covers the main investigation lifecycle: start, get findings, inject hints, trace code, pause, get examples, and submit report. Missing operations like direct arbitrary SPL querying are partially handled through investigate_start and submit_report queries. Overall, it's well-scoped with minor gaps.