The agent works through tools: bounded, size-capped operations against your Splunk deployment, every one of them executed with the calling user’s own session. This page lists them. Read-only tools run on their own (under the default approval mode); the authoring tools always pause for approval; and unattended runs never get the authoring tools at all.
Explore and search
| Tool | What it does |
|---|---|
profile_data | Profiles the data matching a filter in one call: total volume, breakdown by index and sourcetype, activity over time, the fields that exist with their top values, and a few sample events. The intended first step for a broad “analyze X” request. |
splunk_search | Runs a bounded search and returns the rows. Rejects SPL that writes or leaves the search sandbox (delete, collect, outputlookup, sendemail, script, rest, and others) and refuses real-time time ranges. It reads command names, so it refuses a search that calls a macro or a savedsearch: dataset rather than run one unchecked, and asks for the expanded SPL or the explicit command instead. A search that fails after it starts is reported as the failure it is, with the same message the search bar shows. |
verify_spl | Checks that a search parses before it is used or saved. |
list_indexes | The indexes you can search. |
current_time | The current time, so relative ranges are computed correctly. |
Your deployment’s vocabulary
The bundled documentation describes Splunk; these tools describe your Splunk, as the signed-in user sees it:
| Tool | What it returns |
|---|---|
list_macros | Search macros with their definitions, arguments, and the exact backticked call to paste into SPL. |
list_lookups | Lookup definitions with their type (file, KV Store, external, geospatial), the fields they expose, and a starting lookup or inputlookup line. |
list_datamodels | Data models, their dataset trees, and each dataset’s fields with the fully qualified names a data model search requires, plus ready tstats and datamodel searches and which models are accelerated and how far back. |
list_installed_commands | The SPL commands your installed apps contribute, which the bundled reference has never heard of. |
list_kvstore_collections | KV Store collections with their declared fields. |
list_users | User accounts and the roles they hold. |
splunk_server_info | The Splunk version, server roles, and platform this app runs on. |
list_savedsearches, get_savedsearch | Existing reports and alerts, to iterate on. |
list_dashboards, get_dashboard | Existing dashboards, to iterate on. |
list_alert_actions | The alert actions installed on the system - email, webhook, Slack, PagerDuty - discovered rather than guessed. |
The agent is told to survey this vocabulary before writing SPL for an environment it has not seen, and to reuse what is there rather than reinvent it.
Author, with your approval
| Tool | What it does |
|---|---|
create_dashboard, update_dashboard | Create or update a Dashboard Studio dashboard - from a compact panel list (title, search, visualization per panel) that the app expands into a full definition with a tiled layout and a global time-range picker, which also makes the approval card a reviewable list of searches; or from a raw definition for advanced layouts. Panels are checked against the visualization types the app knows, and an unrecognized type is flagged on the approval card rather than silently saved. |
create_savedsearch, update_savedsearch | Create or update a saved search, report, or alert: cron schedules and time ranges, count-based or custom trigger conditions, real-time alerts with throttling and suppression, severity, and any installed alert action. |
verify_dashboard | Validates a dashboard definition before it is written. It changes nothing, so it runs without an approval card. |
The create and update tools pause on an approval card in Chat, and updates are limited to your own private objects.
The reference it consults
The binary embeds a cleaned copy of Splunk’s SPL Search Reference and Dashboard Studio documentation, plus curated dashboard examples, and exposes them as lookup tools (list_spl_commands, get_spl_command, list_dashboard_docs, get_dashboard_doc, and get_dashboard_examples). The agent consults them while it works, so SPL semantics and dashboard syntax come from documentation rather than model memory, and they work air-gapped. Because that reference is a snapshot of one release, the agent also asks your Splunk which version it runs and prefers long-standing syntax on an older or newer deployment.
Query templates
A template records one of your team’s conventions: a name, a description, tags, and the SPL pattern - “application logs live in index=app_prod”, “start from this accelerated tstats”, “this sourcetype needs this filter before its numbers mean anything”. The agent searches the library before writing a search of its own (search_query_templates, get_query_template), adapts the closest match, and says which template it started from.
Manage the library on the Setup page’s Query templates tab. It is shared: readable by every user of the agent, editable by app administrators. A deployment with no templates behaves as if the feature did not exist.
Situational guidance
Beyond its always-on playbook, the agent carries short notes that matter enormously when a request touches them and not at all otherwise, and it adds only the ones a request touches, selected on the words in your message: that a metric index needs mstats, that a subsearch truncates at its limits without an error, that an alert without suppression gets muted. Nine ship with the app, all about SPL and Splunk itself; what is particular to your data - which index an application logs to, which fields it carries - is what your own notes are for. You can add your own, customize a shipped one, or turn one off on the Setup page’s Guidance tab; see Configuration - guidance.