MCP Server tools

The Splunk MCP Server provides several tools to interact with Splunk software.

Tool namespacing

Tools are namespaced based on their source. See the following table for prefix and source information:

Prefix Source
splunk_ Splunk core platform tools
saia_ Splunk AI Assistant tools
o11y_ Splunk Observability tools
es_ Splunk Enterprise Security tools
Note: Splunk platform tools are turned on by default.

The Splunk MCP Server provides tools to interact with Splunk software. See the following table for Splunk core platform, Splunk AI Assistant, and Splunk Observability tool names and descriptions.

For Enterprise Security tool names and descriptions, see Use the Splunk MCP Server app to access tools in Splunk Enterprise Security in the Splunk Enterprise Security User Guide.

Tool name Description Date added
splunk_run_query Execute a Splunk search query and return the results. This is the primary tool for running Splunk searches using Splunk Search Processing Language (SPL). Use this to retrieve log data, perform aggregations, analyze events, and extract insights from your Splunk environment.

Version 1.3 and higher of MCP Server supports SPL2 as well as SPL searches. SPL2 runs with the same guardrails and includes the following commands:

  • fasearch

  • multireport

  • sdselect

  • return

  • timewrap

  • cluster

The prefix of @spl2 is required, as shown in the following example:

PYTHON 
@spl2 from index:_internal\n | stats count() as event_count Response -> 5092017

For more information on SPL2 see theSPL2 Search Reference​ manual.

Version 1.3 and higher offers workload management for the splunk_run_query tool. For more information see the Guardrail triggers and workload management for splunk_run_query section.

 July 2025
splunk_get_info Get comprehensive information about your Splunk instance. Retrieves system information including version, hardware specifications, and operational status. July 2025
splunk_get_indexes Get a list of indexes from Splunk. Indexes are data repositories where machine data is stored and organized. July 2025
splunk_get_index_info Get detailed information about a specific Splunk index. Returns comprehensive configuration and status information for the specified index. July 2025
splunk_get_metadata Retrieve metadata about hosts or sources across 1 or more indexes in the selected time window. For sourcetypes, use splunk_get_sourcetypes. July 2025
splunk_get_user_info Retrieves detailed information about the currently authenticated user including roles and permissions. Returns comprehensive user profile data for the current session. July 2025
splunk_get_user_list Get a list of users from Splunk. Retrieves information about all users including authentication details, roles, and account status. July 2025
splunk_get_kv_store_collections Get KV Store collection statistics including size, count, and storage information. Retrieves comprehensive metrics about all KV Store collections in the Splunk instance. July 2025
splunk_get_knowledge_objects Retrieve Splunk knowledge objects by type. Supports various knowledge object types including saved searches, alerts, field extractions, lookups, macros, and data models. Refer to the full list of supported types later in this topic. July 2025
splunk_run_saved_search Lets AI assistants run your existing Splunk saved searches directly through MCP. See Run Saved Search. April 2026
splunk_list_alerts Lists alerts accessible to the current user, with optional filtering by app, enabled state, and severity. September 2026
splunk_get_alert_details Retrieves the configuration of a specified alert, including its search, schedule, trigger conditions, throttle configuration, notification actions, owner, and enabled state. September 2026
splunk_list_fired_alerts Lists active, unexpired fired alerts, with optional filtering by app and severity. September 2026
splunk_get_fired_alert_details Retrieves recent fired instances for a specified alert, including fire time and severity. September 2026
splunk_get_alert_throttle Retrieves the current throttle configuration and suppression state for a specified alert, including the suppression window and remaining time when active. September 2026
splunk_list_active_throttles Lists alerts that are currently suppressing notifications, including their suppression criteria, window duration, and remaining time. September 2026
splunk_get_sourcetypes Lists sourcetypes that have indexed data, including event counts and first and last event times, with optional filtering by index and time range. September 2026
splunk_get_fired_alert_results Retrieves the results that triggered a specific firing of an alert. October 2026
splunk_get_alert_action_status Checks whether each action for a specific alert firing succeeded, failed, or did not run. October 2026
splunk_find_silent_alerts Lists enabled alerts that haven't fired in the last 90 days or a shorter specified window. October 2026
saia_find_data_source Use natural language to surface the data you want searched, rather than searching all indexes. Results are presented as a shortlist, ranked by relevance.
Note:

To use saia_find_data_source, Agent Mode must be turned on in Splunk AI Assistant. Agent Mode requires Splunk Enterprise version 10.1.x or higher. To learn more, see Agent Mode in Splunk AI Assistant.

Note: This tool was offered as a preview with MCP version 1.3.
July 2026
saia_generate_spl Generate SPL from natural language searches using Splunk AI Assistant for SPL. September 2025
saia_explain_spl Explain SPL queries in natural language using Splunk AI Assistant for SPL. Converts complex SPL commands into human-readable explanations. September 2025
saia_optimize_spl Optimize SPL searches using Splunk AI Assistant for SPL. Improves search performance, efficiency, and follows best practices. September 2025
saia_ask_splunk_question Ask natural language questions about Splunk using Splunk AI Assistant for SPL. Get explanations about Splunk commands, concepts, features, and best practices. September 2025
o11y_get_apm_services Retrieves a list of APM services for a given environment. September 2026
o11y_get_apm_environments Gets a list of APM environments. September 2026
o11y_get_apm_service_errors_and_requests Provides a breakdown of service errors and requests by tag. September 2026
o11y_get_apm_service_latency Provides a breakdown of service latency by tag. September 2026
o11y_get_apm_service_dependencies Gets upstream and downstream service dependencies. September 2026
o11y_get_apm_trace_tool Returns trace errors and spans for a given trace ID. September 2026
o11y_get_apm_exemplar_traces Gets exemplar traces for a service. September 2026
o11y_get_apm_profiling_data Retrieves read-only CPU or memory profiling hotspot data for a specified service and time range. Supports optional environment, host, container, and process filters. October 2026
o11y_search_alerts_or_incidents Retrieves alerts or incidents triggered by detectors. September 2026
o11y_get_metric_names Gets existing metric names by wildcard search September 2026
o11y_get_metric_metadata Retrieves dimensions and properties for given metrics. September 2026
o11y_generate_signalflow_program Generates a Splunk SignalFlow program from natural language. September 2026
o11y_execute_signalflow_program Executes a SignalFlow program and returns results. September 2026

APM profiling with MCP Server

The o11y_get_apm_profiling_data tool retrieves read-only CPU or memory hotspot data for a specified service and time range. You can optionally filter results by environment, host, container, or process.

See the following table for more information:

Property Description
Inputs Requires service_name and profiler_type (CPU or MEMORY). Supports time_range and optional environment, host, container, and process filters.
Response Returns aggregated, sanitized profiling hotspots, including total_count and hotspots. Results include profiling values and sample counts, not percentages.
Time range Defaults to the most recent 15 minutes. Maximum query window is 60 minutes.
Result limit Defaults to 25 hotspot rows. Accepts values from 1 through 100.
Environment limit Supports up to 20 environments per request.
Authorization Requires Capability.APM. The tool uses the caller's existing APM authorization.
Read-only behavior Does not modify profiling settings or retrieve raw profiles. Direct pprof access and port-forwarding aren't required.
Empty results

If no profiling samples match the request, the tool returns a successful response with an empty hotspots list.
Partial results The response does not include a partial-result indicator.
Known limitations Does not return flame graphs, percentages, or profiling configuration. Data availability depends on the realm, service, environment, and time range. Host, container, and process filters require exact identifiers.
Error behavior Invalid requests return validation errors. Timeouts, authorization failures, backend failures, and malformed responses return errors rather than empty or partial results.

Input parameters

The following table describes the input parameters for the o11y_get_apm_profiling_data tool:

Parameter Required Description
service_name Yes Name of the APM service to query.
time_range No Object containing start and stop. Accepts ISO 8601 timestamps, relative durations such as -30m, or POSIX timestamps. Defaults to the most recent 15 minutes. Maximum interval is 60 minutes.
profiler_type Yes Type of profiling data to retrieve: CPU or MEMORY.
environment_names No List of environments to filter by. Supports up to 20 environments.
host_name No Filters profiling data by host.
container_id No Filters profiling data by container.
process_pid No Filters profiling data by process ID. Must be zero or greater.
limit No Maximum number of hotspot rows to return. Defaults to 25. Accepts values from 1 through 100.
Note: The Observability realm is determined by the MCP endpoint and authentication token and is not specified as a tool input. To filter profiling data within that realm, use the optional environment_names parameter.

Response fields

The following table describes the fields returned by the o11y_get_apm_profiling_data tool:

Field Description
service_name Name of the APM service queried.
profiler_type Profiling type returned: CPU or MEMORY.
start_time_ms Start of the queried time range, in milliseconds.
end_time_ms End of the queried time range, in milliseconds.
total_count Sum of the counts across the returned hotspot rows. This is not the total sample count for the entire queried time range.
hotspots List of aggregated profiling hotspots. Each hotspot contains the frame, value, and count fields.
frame Stack frame associated with the profiling hotspot.
value Profiling value associated with the hotspot.
count Count associated with the hotspot.

Examples

See the following CPU and memory examples.

CPU profiling example:

JSON 
{
  "service_name": "apm-sessionizer",
  "time_range": {"start": "-15m", "stop": "now"},
  "profiler_type": "CPU",
  "environment_names": ["production"],
  "limit": 5
}

Memory profiling example:

JSON 
{
  "service_name": "apm-sessionizer",
  "time_range": {"start": "-15m", "stop": "now"},
  "profiler_type": "MEMORY",
  "environment_names": ["production"],
  "limit": 5
}

Guardrail triggers and workload management for splunk_run_query

The splunk_run_query tool is the primary tool for running Splunk searches using Splunk Search Processing Language (SPL) and SPL2.

Note: Support for SPL2 is available with version 1.3 and higher. When searching with SPL2 the

prefix of @spl2 is required.

Guardrail triggers

The splunk_run_query tool is intended for quick searches that are deemed safe and non-destructive. The tool might fail and trigger a guardrail for 1 or more of the following reasons:

  • If the search contains commands that are deemed unsafe or destructive, the MCP server might not execute the search.
  • The execution time exceeds 1 minute.
  • The number of events in the response exceeds 1000.

Workload management

When running Splunk MCP Server version 1.3 and higher you can use workload management to create a workload pool for the splunk_run_query tool.

Workload management (WLM) can help allocate system resources among different workloads. Workload pools define how those resources are assigned. Taking this step moves splunk_run_query into a detached, asynchronous search job.

  • For detailed steps on creating workload pools in Splunk Enterprise see Configure workload pools in the Administer Splunk Enterprise manual.

  • Splunk Cloud Platform users can learn more about workload pools in Workload Management overview in the Administer Splunk Cloud Platform manual.

To use the workload pool call splunk_run_query with the exact pool identifier as shown in the following example:

JSON 
{
  "method": "tools/call",
  "params": {
    "name": "splunk_run_query",
    "arguments": {
      "query": "| makeresults | eval marker=\"mcp_pool_probe\"",
      "workload_pool": "mcp_low_priority"
    }
  }
}

Supported knowledge object types

The following knowledge object types are supported by get_knowledge_objects:

  • saved_searches

  • alerts

  • field_extractions

  • field_aliases

  • calculated_fields

  • lookups

  • automatic_lookups

  • lookup_transforms

  • macros

  • tags

  • data_models

  • workflow_actions

  • views

  • panels

  • apps

  • mltk_models

  • mltk_algorithms