MCP Server REST command support

The splunk_run_query tool supports the rest SPL command. This support is available when running Splunk MCP Server version 1.3 or higher.

AI agents can query any Splunk REST endpoint including users, roles, licenses, inputs, cluster health, through a single tool, with no custom integration required. The command calls the Splunk internal REST API and returns the response as a structured, searchable result that can be filtered and shaped with standard SPL.

Note: The rest command is read-only.. It cannot create, update, or delete anything in your Splunk environment.

Key features

See the following table for key features with the version 1.3 and higher rest command support:

Version 1.2.1 and lower Version 1.3 and higher
A separate HTTP client or custom MCP tool was required for each REST endpoint A single splunk_run_query call covers every Splunk REST endpoint
AI agents had no visibility into Splunk admin state (users, roles, licenses, inputs, cluster) Agents can audit users, licenses, inputs, and cluster health on demand
Each new operational use case required custom integration work Every documented Splunk REST endpoint is immediately accessible through SPL

Guardrails and constraints

See the following table before you begin:

Note: These constraints apply to all rest command usage through splunk_run_query.
Constraint Details
Command is read-only The rest command uses method=GET by default. POST and DELETE are blocked by splunk_run_query guardrails. The command cannot modify, create, or delete any Splunk configuration or data.
User permissions are in effect Requests execute under your authenticated session. If you do not have access to an endpoint, it returns an error. This is the same results as calling it directly through the REST API.
1,000 event result maximum The splunk_run_query tool returns a maximum of 1,000 events. Use head, where filters, or the count= parameter to narrow results for large environments.
Note: Using count=0 requests unlimited results from the REST endpoint but the 1,000-event MCP maximum still applies.
60-second timeout Queries that exceed 60 seconds are terminated. Multi-step queries combining rest with join or subsearches can approach this limit on large deployments. If a query times out, you can break it into smaller steps.
Splunk endpoints only Only Splunk-internal paths starting with /services/ or /servicesNS/ are accessible. External URLs are not reachable.
Errors surface as SPL errors A bad endpoint path, permission error, or unreachable peer returns a Splunk search error, not an empty result set. Handle accordingly in agent logic.
Audit logging The rest queries that run through splunk_run_query are logged in Splunk's search audit logs (index=_audit) the same as any other search, giving full visibility into what an AI agent queried.

SPL rest command reference

The rest command is placed at the start of a search and pulls data from Splunk's internal admin API. The response comes back as a searchable table you can filter with standard SPL.

Syntax

See the following example syntax for calling the rest command:

CODE 
| rest <endpoint> [splunk_server=<server>] [count=<int>] [<field>=<value> ...]

And see the following table for a full parameter reference:

Parameter Description
endpoint Required. Must start with /services or /servicesNS.

Example: /services/data/indexes
splunk_server Target a specific peer in a distributed deployment. Use the wildcard ( * ) to query all peers simultaneously. See the Guardrails and constraints section for more information.
splunk_server_group Target a named server group, e.g. an indexer cluster peer group.
count Maximum results to return from the REST endpoint per server. Default is 30. Set to 0 to request all results.
Note: The MCP 1,000-event cap still applies.
timeout Request timeout in seconds. Default is 30.
offset Starting position for paginating through large result sets.
field=value Additional query parameters passed to the endpoint.

How results work

The response JSON is flattened into a table. Each top-level key becomes a column. Nested objects use dot notation, for example eai:acl.owner. Pipe the output to | table, | where, | eval, or | stats to shape it.

Namespace-scoped requests

Use /servicesNS/{user}/{app}/ to scope requests to a specific app context. Use this for KV Store collections, lookups, and data models that are app-scoped, as shown in the following example:

CODE 
| rest /servicesNS/admin/search/saved/searches

Use cases and examples

The following examples show the natural language prompt an AI agent would receive, the resulting SPL query, and what the agent returns. The "Before" information shows what was required previously, before the rest command support.

Example: Full RBAC audit including users, roles, and capabilities

Who asks for this: Security teams, compliance auditors

Prompt: Give me a complete picture of which users have which capabilities in this environment.

Before: Required three separate tool calls plus manual cross-referencing in Splunk Web.

CODE 
| rest /services/authentication/users count=0
| mvexpand roles
| rename roles as role_name, title as username
| join type=left role_name
    [| rest /services/authorization/roles count=0
     | mvexpand capabilities
     | stats values(capabilities) as capabilities by title
     | rename title as role_name]
| mvexpand capabilities
| stats values(capabilities) as capabilities, values(role_name) as roles by username
| sort username

Returns: Every user mapped to their roles and every capability those roles grant, ready for a compliance report.

Example: Indexer cluster health check

Who asks for this: On-call SREs, platform engineers

Prompt: Are all my indexer cluster peers healthy and replicating correctly?

Before: Required direct cluster manager access or navigating the Splunk Web Monitoring Console.

CODE 
| rest /services/cluster/master/peers count=0
| eval statusColor=case(status="Up","green",status="Restarting","yellow",1=1,"red")
| table label status statusColor site replication_count bucket_count last_heartbeat
| sort status

Returns: A peer-by-peer health matrix with replication counts, bucket totals, last heartbeat, and a computed status. All the data needed to decide if remediation is required, without leaving the AI conversation.

Note: This endpoint is only available in clustered Splunk deployments. It returns an error on standalone instances.

Example: License pool headroom and top

Who asks this: Splunk admins, FinOps, renewal teams

Prompt: Are we at risk of exceeding our license? Which indexes are consuming the most?

Before: Not accessible through any MCP tool. Required navigating to Settings and then to Licensing in Splunk Web.

CODE 
| rest /services/licenser/pools count=0
| eval usedGB=round(used_bytes/1073741824,2)
| eval quotaGB=round(effective_quota/1073741824,2)
| eval headroomPct=round((1-(used_bytes/effective_quota))*100,1)
| table title usedGB quotaGB headroomPct
| sort headroomPct

Follow with this query to find the top license consumers:

CODE 
index=_internal source=*license_usage.log type=Usage
| stats sum(b) as bytes_ingested by idx
| eval GB=round(bytes_ingested/1073741824,3)
| sort -GB | head 10
| table idx GB

Returns: License pool headroom percentages alongside the top 10 indexes by ingestion volume.