All five tools are reads — nothing here runs a search or edits a saved object, which makes it safe to point an agent at production. The prompt is the interesting part: it pushes the client to enumerate indexes and macros before interpreting an alert, which is where a Splunk answer usually goes wrong.
A Go server over the Splunk REST API. Five read tools, plus a prompt that instructs the client to survey alerts, indexes and macros before it answers a question.
- Saved searches listed, up to 100 at a time with an offset — list_splunk_saved_searches
- Alerts listed and narrowed by a case-insensitive title substring — list_splunk_alerts
- Fired alerts over a look-back window, default -24h, filtered by search name pattern — list_splunk_fired_alerts
- Indexes and macros listed with count and offset — list_splunk_indexes, list_splunk_macros
- A prompt that finds alerts for a keyword such as GitHub or OKTA and tells the client to read alerts, indexes and macros first
- A resource carrying Splunk-related content as extra context
- Both stdio and SSE transports from the same binary
SPLUNK_URL pointing at the management port of your instance, for example https://your-splunk:8089, and SPLUNK_TOKEN. Build with go build, then run the binary directly for stdio or with -transport sse -port 3001 for SSE. A Dockerfile and a smithery.yaml are included for hosted deployment.