This server enables AI agents to conduct structured, multi-iteration Splunk investigations entirely on-device, using deterministic detectors and iterative reporting.
Start an investigation (splunk__investigate_start): Load a local Splunk export (JSON/CSV) or run a live SPL query; triggers detectors (spike detection, cert anomalies, slow queries, numeric anomalies, host rankings, etc.) and returns structured findings with a run_id.
Submit reports and follow-up queries (splunk__submit_report): Submit a markdown report (with confidence level) and optional follow-up SPL queries; the server executes queries, generates new findings, and signals whether to continue iterating or conclude.
Retrieve current findings mid-loop (splunk__get_findings): Inspect the latest detector output for an active investigation without advancing the loop.
Pause an investigation (splunk__pause): Gracefully stop the investigation loop after the current iteration completes.
Inject analyst hints (splunk__hint): Provide a hint (e.g., "focus on web-01 after 14:30 UTC") to guide the next reasoning iteration.
Retrieve example SPL queries (splunk__query_examples): Pull historical SPL queries from past investigations (optionally filtered by area such as "tls" or "auth") to ground new queries in proven field names and patterns.
Trace code call chains via LSP (splunk__lsp_call_chain): Given a function or symbol, trace callers/callees through microservice source code to identify which code path produced a specific log error — bridging findings directly to source code (requires a repo path at investigation start).
Provides tools for investigating Splunk data by ingesting exports (JSON/CSV) or running live SPL queries, applying deterministic detectors, and managing an investigation loop with findings and reports.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Splunk Intelligence MCP Server Investigate cert_errors.json for anomalies"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local Splunk investigation stack that ingests exports (JSON/CSV) or runs live SPL queries, applies deterministic detectors, and drives a structured multi-iteration investigation loop via MCP tools exposed to AI agents (GitHub Copilot or Claude Code). Everything runs on-device — no data leaves the machine.
Splunk export (JSON/CSV) ──or── Splunk REST API
└─> parsers.py # Polars DataFrame: field extraction, timestamp normalisation
└─> detectors.py # rule-based: spikes, patterns, cert anomalies, correlations,
│ # severity, host rankings, slow queries, numeric anomalies
└─> connector.py # facade: loading, detection, run state — no HTTP, no server
│ # process; MCP tools, the TUI, runner.py, and its own CLI
│ # all call into it directly
└─> mcp_server.py # FastMCP: exposes investigation tools to Copilot / Claude
└─> tui.py # terminal UI: run history + live progress, reads splunk.db directly
└─> runner.py # CLI orchestrator
└─> reports/ # generated markdown reports
└─> logs/ # per-run JSONL structured logs (audit trail — every
│ # investigate/pause/hint/done action, not just the CLI pipeline)
└─> splunk.db # SQLite: events, findings, reports, queries, active_runs, alerts per run_id
standalone/ # top-level dir: processes that run outside the MCP/agent loop
└─> agent.py # optional: standalone LangGraph ReAct loop (--investigate flag),
│ # via splunk/llm_backends.py — ollama / claude_cli / copilot_cli
└─> watcher.py # standalone process (python -m standalone.watcher) — polls Splunk on an
# interval, runs detectors, writes hits to splunk.db's alerts table;
# consumed via splunk__check_alerts / splunk__ack_alertThe investigation loop is self-contained — splunk__submit_report returns {status, findings, next} and the agent loops on its own without external hooks.
Copilot/Claude via MCP is the primary reasoning path — no Ollama or CLI subprocess required. For environments without either, standalone/agent.py provides an optional standalone LangGraph ReAct agent, enabled via uv run python -m splunk --input <file> --investigate (requires uv sync --extra llm). See Standalone agent below for backend options.
Related MCP server: Splunk MCP for SOC Operations
Python 3.12+
uv — brew install uv
Splunk instance URL (set SPLUNK_URL env var; required for live queries only)
uv sync --extra dev
uv run playwright install chromiumecho "SPLUNK_URL=https://your-splunk-instance:8089" > .envuv run python -m splunk.authThis opens a visible Chromium window via Playwright. Complete the SSO login manually. The session cookie is saved to ~/.splunk/auth.json and loaded automatically on every live query. Re-run when your session expires (Splunk uses SSO/SAML — password login is not available).
# From a local export file
uv run python -m splunk --input results/cert_errors.json
# Live SPL query
uv run python -m splunk --live --spl "index=pki sourcetype=ocsp_error" --earliest -6hNo server process required — start the MCP tool server, and optionally the TUI:
# Terminal 1 — MCP tool server
uv run python -m splunk.mcp_server
# Terminal 2 (optional) — terminal UI for watching live investigation progress
uv run python -m splunk.tuiThen ask Copilot or Claude: "Start a Splunk investigation on results/cert_errors.json"
The agent calls splunk__investigate_start, reasons over findings, and loops via splunk__submit_report until confident. See AGENTS.md for the full loop protocol.
The TUI reads splunk.db directly for run history and the rendered report, and polls the active_runs table for live iteration/confidence/event-count every ~2s — no HTTP involved. Because every connector function writes to active_runs regardless of which process calls it, the TUI shows live per-iteration progress for both MCP/Claude-driven investigations and the standalone --investigate agent path — previously (before this design), MCP-driven progress was invisible to any other process since it only lived in an in-memory dict inside whichever process was running it.
Same investigation engine, no MCP tool-calling required:
uv run python -m splunk.connector start --source results/cert_errors.json
uv run python -m splunk.connector submit-report --run-id <id> --report "..." --queries "-- area\nindex=pki ..."
uv run python -m splunk.connector get-findings --run-id <id>
uv run python -m splunk.connector pause --run-id <id>
uv run python -m splunk.connector hint --run-id <id> --text "focus on web-01 after 14:30 UTC"--investigate)For environments without Copilot or Claude Code driving MCP tools directly, standalone/agent.py
runs its own LangGraph ReAct loop over the same detector findings and produces the same kind of
markdown report. It's a fallback, not the primary path — prefer the MCP flow above when available.
uv sync --extra llm # pulls in langgraph, langchain-core, langchain-ollama
uv run python -m splunk --input results/cert_errors.json --investigateThe chat backend driving the loop is selected via SPLUNK_AGENT_BACKEND (default ollama):
Backend | Requires | Notes |
|
| Model via |
|
| No API key needed — reuses your existing login. Model via |
|
| No API key needed. Model via |
# Ollama (default) — needs `ollama serve` running and the model pulled
ollama pull qwen2.5:14b
uv run python -m splunk --input results/cert_errors.json --investigate
# Claude CLI — no separate server process, reuses your `claude` login
SPLUNK_AGENT_BACKEND=claude_cli \
uv run python -m splunk --input results/cert_errors.json --investigate
# Copilot CLI
SPLUNK_AGENT_BACKEND=copilot_cli \
uv run python -m splunk --input results/cert_errors.json --investigateclaude_cli/copilot_cli shell out to the CLI non-interactively (claude -p / copilot -p)
with the CLI's own tool use disabled, bridging tool-calling by hand via a small JSON protocol —
see splunk/llm_backends.py and splunk/cli_tool_protocol.py for how. One CLI session is opened
per investigation and reused (--resume) across all ReAct iterations rather than starting cold
every turn.
SPLUNK_AGENT_MAX_ITER (default 10) caps ReAct loop iterations regardless of backend.
/splunk-investigate <input> — the investigation loop (splunk__investigate_start →
reason over findings → splunk__submit_report → repeat). <input> is a file path or an
SPL query — one skill handles both:
/splunk-investigate results/cert_errors.json or
/splunk-investigate "index=pki sourcetype=ocsp_error" --earliest -6h
If invoked with no argument, it asks.
Tool | Purpose |
| Load file or live SPL query, run detectors, return structured findings + |
| Submit a markdown report and follow-up SPL queries; returns |
| Read current findings for an active run without advancing the loop |
| Stop the loop after the current iteration |
| Inject an analyst hint that shapes the next iteration |
| Return past SPL queries from |
| Trace a function/symbol through a microservice's call graph to find which code path produced a log error (requires |
| Read unacknowledged alerts written by the standalone watcher ( |
| Mark a watcher alert as acknowledged so it stops appearing in |
An interactive onboarding prompt is available for GitHub Copilot. In VS Code Copilot Chat, attach .github/prompts/onboard.prompt.md via the # file picker — Copilot will walk you through setup, auth, and running your first investigation.
uv run pytest tests/Tests are fully deterministic — no Splunk connection, no server required. Fixtures live in tests/fixtures/.
--live path locallylocal_splunk/ provides a throwaway single-instance Splunk container (Docker, based on
splunk/docker-splunk) for exercising --live
queries against a real Splunk REST API and real SPL execution — without production credentials
or SSO. See local_splunk/README.md for setup/teardown steps.
File | Purpose |
| All tunables — thresholds, paths, auth |
|
|
|
|
| Facade: loading, run state, standalone agent loop, |
| FastMCP server — 9 investigation tools (thin wrappers over connector.py) |
| Terminal UI — |
| CLI entry point |
| Splunk REST client (cookie-based, SSO-compatible) |
| Playwright SSO — opens Chromium, saves cookie |
| SQLite store: events, findings, reports, queries, active_runs, alerts, per-sourcetype schema cache |
| Structured JSON-lines logging per run — audit trail for every connector action |
| Standalone |
| Standalone LangGraph ReAct agent ( |
| Pluggable chat backend for |
| Registry of investigation domains (prompt + SPL template) consumed by |
Variable | Default | Purpose |
| — | Splunk base URL (required for live queries) |
|
| Default index substituted into generated follow-up SPL (standalone agent path) |
| — | Comma-separated indexes relevant to your environment — reference only, surfaced to the user during the live-SPL preflight; doesn't affect |
|
| MCP-driven investigation loop's iteration cap (primary path — |
|
| Event-pair correlation window (seconds) for |
|
| Events/window to trigger a spike |
|
| Spike detection window (seconds) |
|
| Duration (ms) above which an event is flagged as a slow query |
|
| Rolling window size (events) for z-score anomaly detection |
|
| |z-score| above which an event is flagged as a numeric anomaly |
|
| Splunk session cookie name |
|
| Cookie persist path |
|
| Live REST job polling interval (seconds) |
|
| Live REST job poll timeout (seconds) |
|
| Max silent re-auth attempts on a 401 before failing |
|
| Log verbosity |
|
| Standalone agent ( |
|
| Ollama model (backend |
|
| Model passed to |
|
| Model passed to |
|
| Standalone agent ReAct loop cap |
| — | SPL query the watcher ( |
|
| Seconds between watcher poll cycles |
Put these in a .env file at the repo root (gitignored).
Epic planning, subtask creation, task grooming, task implementation using https://github.com/debaditya-mohankudo/Lite-Task-Framework
GitHub Copilot — see AGENTS.md for loop rules, MCP tool reference, and report format
Claude Code — see CLAUDE.md for project conventions and task backlog
Onboarding — see .github/prompts/onboard.prompt.md
Get current findings from the active investigation session. Use this to inspect the latest detector output mid-loop.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only status, auth requirements, or side effects. It only implies a read operation ('Get', 'inspect') without explicit assurance of non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) with no redundant information. The primary purpose is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has an output schema (not shown) and sibling tools like 'splunk__investigate_start' provide context, the description lacks guidance on 'run_id' and the 'active investigation session' concept, requiring the agent to infer from tool names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the 'run_id' parameter—its purpose, format, or how to obtain it. This is a critical gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get[s] current findings from the active investigation session,' specifying the verb 'Get' and resource 'findings.' It distinguishes from siblings like 'splunk__submit_report' by context (active session, mid-loop), though it could be more explicit about what 'current' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool 'to inspect the latest detector output mid-loop,' providing clear context for invocation. However, it does not mention when not to use it or describe alternatives, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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"
| Name | Required | Description | Default |
|---|---|---|---|
| hint | Yes | ||
| run_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior: the hint is included in findings passed to the next reasoning step. However, it omits details like whether multiple hints can be combined, persistence, or mutability, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus a relevant example, front-loaded with the action. No wasted words; efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter design and presence of an output schema, the description covers the main behavior. Minor gaps like whether hints stack or are one-shot, but overall sufficient for a straightforward injection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'hint' with an example but does not define 'run_id', leaving that parameter's purpose unclear. Partial improvement but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool injects an analyst hint into the investigation for the next iteration, with a concrete example. This distinguishes it from siblings which handle findings, pausing, reports, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to inject a hint vs. submit a report or start a new investigation). The description only explains what it does, not the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| spl | No | ||
| latest | No | now | |
| source | No | ||
| earliest | No | -24h | |
| repo_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool loads events, runs detectors, and returns findings. It also mentions the cross-referencing behavior when repo_path is provided. Since no annotations are supplied, the description sufficiently covers the tool's behavior, though it could mention if the operation is read-only or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear overview sentence followed by a focused list of parameter details. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and their interplay, notes prerequisites (SPLUNK_URL for live queries), and states the return format. Given the presence of an output schema, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, the source vs spl trade-off, default time ranges, and the repo_path's role in code cross-referencing. This adds significant value beyond the schema's minimal information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a Splunk investigation, loads events, runs detectors, and returns structured findings. It effectively communicates the primary verb and resource, though it could be improved by explicitly differentiating from siblings like splunk__get_findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use source vs spl parameters and explains the prerequisites for live queries. However, it lacks explicit direction on when to use this tool versus alternative sibling tools, such as when to use splunk__get_findings instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| line | No | ||
| depth | No | ||
| run_id | Yes | ||
| symbol | Yes | ||
| direction | No | callers | |
| file_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the tool returns a JSON call chain or an error if repo_path is missing or symbol unresolved. It doesn't mention destructive behavior (none expected) and gives direction/depth options, providing good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. Each sentence serves a purpose: stating the core action, providing usage context, and detailing parameters. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 2 required, and an output schema exists, the description adequately covers what the tool does and returns. It mentions error conditions. It could mention prerequisites like calling investigate_start first, but the error note indirectly addresses that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description explains all 6 parameters: run_id, symbol, file_path, line, direction, and depth. It gives examples for symbol, explains direction values, default depth, and optional file_path/line, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: tracing a function or symbol through the microservice call graph using LSP, and it is used during the Reason step. It distinguishes itself from siblings like splunk__get_findings and splunk__hint by focusing on call graph tracing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool during the Reason step to find code paths producing log errors. While it does not list when not to use or provide alternatives, the context is clear and sufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause the investigation after the current iteration completes.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action but does not reveal consequences such as whether the investigation can be resumed, if state is saved, or what happens during the pause. This is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no waste. It is appropriately sized for a simple action, though it could benefit from additional context without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has one parameter and an output schema, the description is incomplete. It does not explain what the output contains, what 'current iteration' means in this context, or any necessary preconditions (e.g., investigation must be running). More completeness is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema does not describe the param. The tool description also fails to describe the 'run_id' parameter or its role. The description adds no semantic value beyond the schema for the parameter, and it does not compensate for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('pause') and the resource ('the investigation after the current iteration completes'). It uses a specific verb and resource, and it largely distinguishes from sibling tools which perform different functions (e.g., get_findings, hint). However, it could be slightly more precise about what 'iteration' refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or any context for invocation. This is a gap for a tool that presumably controls execution flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It transparently describes the output structure (JSON list with fields like area, spl, result_rows, etc.) and behavior (sorted by most recent first). No contradictions observed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, though the Args block adds some verbosity. Overall, every sentence adds value, and it is appropriately sized for the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description need not explain return values in detail, but it does so anyway. It covers all necessary aspects: what the tool does, when to use it, parameter details, and output format. Complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It does so by explaining both parameters: area with filtering guidance and example labels, and limit with default value. This adds meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns example SPL queries from past investigations, using the specific verb 'Return' and resource 'example SPL queries'. It distinguishes from sibling tools by emphasizing that these examples are from past investigations in splunk.db, providing grounding for follow-up queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to ground follow-up queries in field names and patterns', providing clear usage context. However, it does not explicitly state when not to use or contrast with siblings, but the implied usage is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | ||
| run_id | Yes | ||
| queries | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the lifecycle: stores report, executes queries, builds findings, and returns status with either findings or a UI URL. It does not cover error handling, rate limits, or side effects like overwriting, but provides reasonable transparency for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief introduction followed by an Args section listing parameters and their meanings. No extraneous information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the main workflow and return types. It does not detail the output schema content but mentions status and fields, which is sufficient for an agent to understand the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains run_id as coming from splunk__investigate_start, report as markdown with confidence level, and queries as SPL strings starting with '-- area' comment. This adds significant detail beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: submitting an investigation report and follow-up SPL queries to the server. It explains the workflow of storing, executing, and returning results, distinguishing it from sibling tools like splunk__get_findings (retrieval) or splunk__investigate_start (initiation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the run_id parameter comes from splunk__investigate_start, implying usage after that tool. It does not explicitly exclude scenarios or mention alternatives, but the context is clear. Sibling tool names provide implicit guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
The AI orchestration agent for modern software teams.
150+ vertical AI expert bots as agent tools. $1 bots run on YOUR machine - your data stays yours.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/debaditya-mohankudo/splunk-intelligence'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
