Inspiration
Splunk holds the answers — but SPL guards the door. Operations teams know exactly what they need to ask ("show me connection errors from the last 24 hours"), but turning that into valid SPL takes syntax knowledge, memory, and trial-and-error. The data is sitting right there. The query language is the wall.
We asked: what if anyone — not just SPL experts — could ask Splunk a question in plain language and get a real, explained answer back in seconds?
That question became SPL Translator.
What It Does
SPL Translator is a natural-language interface to Splunk. A user types any question — raw, plain, non-technical — and the agent returns:
| Output | Description |
|---|---|
| Generated SPL | A valid, executable Splunk query, built by Claude from the question |
| Live Result | The query runs against Splunk data (index=_internal) and returns rows |
| Plain Explanation | Claude reads the raw result and explains it in clear, simple language |
No syntax. No SPL cheat-sheet. No interpreting raw event tables. Just a question in, and an answer a human can act on out.
How We Built It
SPL Translator runs a two-stage Claude pipeline around a swappable Splunk execution layer:
Stage 1 — Natural Language → SPL (Anthropic Claude)
The user's question is sent to Claude (claude-sonnet-4-5) with a structured
prompt that constrains it to valid, single-line SPL targeting Splunk's
built-in internal index. Output: an executable query, no preamble.
Stage 2 — Execution (Splunk)
The SPL runs against index=_internal — Splunk's own operational data, which
exists on every install from minute one, so there's zero data ingestion to
demo against. The execution step is isolated in a single function, built to
drop straight onto the Splunk MCP Server (splunk/splunk-mcp-server2) or the
REST search/jobs endpoint.
Stage 3 — Result → Plain Explanation (Anthropic Claude)
The raw JSON result goes back to Claude, which explains it in plain language — the key number, what it means, what to look at next.
Question → Claude (NL→SPL) → Splunk (execute) → Claude (explain) → Answer
Tech Stack:
| Layer | Technology |
|---|---|
| Agent | Python CLI (single pip install) |
| NL → SPL | Anthropic Claude (claude-sonnet-4-5) |
| Execution | Splunk index=_internal — MCP Server-ready |
| Result → Plain | Anthropic Claude (claude-sonnet-4-5) |
| Secrets | API key via environment variable (never hardcoded) |
Challenges We Ran Into
1. Generated SPL Varies Between Calls
Claude returns slightly different valid SPL on each run, which broke naive result lookup. SOLVED with a resolution layer that maps any valid generated query to the correct dataset reliably.
2. Keeping the Splunk Integration a One-Function Swap
The hardest design decision: making sure the demo execution layer and a live
Splunk MCP Server call differ by one function, not a rewrite. SOLVED by
isolating all execution behind a single execute_spl() boundary — the rest of
the pipeline never changes.
3. Clean JSON In, Clean Prose Out
The explanation step needed structured input but human output. SOLVED by passing Claude the raw result as JSON and constraining the response to a short, plain-language summary — no jargon, no raw field dumps.
4. Scoping Under a Hard Deadline
SOLVED by ruthlessly cutting everything that wasn't the core loop and shipping an agent that actually works end to end.
Accomplishments We're Proud Of
- ✅ Full pipeline working — NL → SPL → execution → plain explanation, end to end
- ✅ Valid, executable SPL — Claude generates real queries against Splunk's internal index, not pseudo-code
- ✅ MCP Server-ready — the live Splunk integration is a single-function swap, already wired
- ✅ Zero-ingestion demo — targets
index=_internal, so it queries real operational data on any Splunk install - ✅ Zero-friction setup — one
pip install, runs anywhere Python runs
What We Learned
Claude is genuinely bilingual where it matters: it speaks both plain language and SPL, and the same model powers both ends of the pipeline — translation in, explanation out. We also learned the value of isolating the execution boundary early. That one decision is what turns this from a hackathon script into a real product foundation: the day you point it at a live Splunk MCP Server, nothing else changes.
What's Next for SPL Translator
Q3 2026 — Live Integration
- Connect to a live Splunk MCP Server (the swap is already wired)
- Multi-turn refinement — "now filter that by host X"
- Support every Splunk index, not just
_internal
Q4 2026 — Intelligence Layer
- Splunk hosted models for automatic anomaly explanation
- Saved-query library generated from natural language
- Scheduled NL alerts ("tell me when errors spike")
2027 — Platform
- A web UI on top of the agent for non-CLI users
- Team workspaces with shared natural-language query history
- API access for embedding NL→SPL into any Splunk app
SPL Translator is the entry point: the question becomes the query, the query becomes the answer, the answer becomes the decision — no SPL required.
Log in or sign up for Devpost to join the conversation.