Splunk MCP Server 2.0: Moving at Agentic Speed, Without Giving Up Control

Your engineers are pointing AI assistants at Splunk. Someone on the SOC team has Claude Code open next to their console. A DevOps engineer wrote a script that scrapes search results into a model.

All of these are scenarios that could be happening in your organization right now, whether they were approved or not. This leaves a Splunk admin with some serious questions to consider.

How are Agents reaching and using our data? Are they able to just pull from whatever anyone has open and wire up on their laptop? How much control and configurability do we have over our agents?

With Splunk MCP server, there’s no need to worry about how agents are using your data because

Today, we’re proud to announce the release of Splunk MCP server 2.0! Our team has been hard at work over the last several releases adding new features and capabilities to Splunk MCP server and this release marks the debut of a variety of new alert tool options, out of the box availability with the release of Splunk Cloud 10.6, and plenty of ways to make sure that while your agents work, your admins still have control where it counts.

Key Features and Updates in 2.0

• MCP Server Right Out of the Box: Starting with the release of Splunk Cloud 10.6, eligible customers get Splunk MCP server preinstalled. Nothing to download, nothing to request. Your admins configure access and your teams connect their clients. This also shortens the path to the rest of the Splunk AI portfolio since MCP server acts as the layer underneath our other tools like Splunk AI Assistant, AI Canvas, Enterprise Security, and ITSI integrations. Now that MCP server is a default application, the power to use all of these capabilities is just one configuration away.
• Wider Surface with Governance: For those that might not have tried Splunk MCP server since launch, there’s plenty of new additions to come back and check out. Agents can now search with SPL2 across federated providers, discover which indexes hold the data they need, reason about your alert estate, and call tools your own team wrote. But fret not, all of these new options are still easy for Splunk admins to control and configure.

Demo: Getting Started with Splunk MCP

Enhancing Your Agents

Search SPL2 and Federated Data

The workhorse behind a number of this release’s improvements is splunk_run_query, which now accepts SPL2. By adding the @spl2 prefix to the query, the server compiles it before execution. This also opens up federated search since a single SPL2 query can now span federated providers. This means an agent investigating an incident can reach data outside the local search head without you needing to build a custom integration for it. The same guardrails that apply to SPL1 also apply here.

Additionally, | rest searches also work with no extra setup, since the rest command is on the safe SPL allowlist by default. This covers a lot of common questions you might have when running a search. Which apps are installed? How is a knowledge object defined? What is this setting currently set to?

Saved searches can be run by name through splunk_run_saved_search, with token substitution and time-range overrides.

Finding the Right Data First

An agent is only as good as its ability to find where relevant data lives. On a deployment with hundreds of indexes and thousands of sourcetypes, that’s no easy task, and a wrong guess can result in a “confidently wrong” answer.

saia_find_data_source uses Splunk AI Assistant's data discovery capability to turn a plain-language question into a ranked short list of candidate indexes, sourcetypes, and key fields. You can ask about failed authentication and get info on the few places that data actually lives, instead of a dump of every index on the system. It runs before an agent writes SPL, so the query it produces points somewhere real.

This tool appears when Splunk AI Assistant for Cloud is installed on your deployment.

Bringing Order to Your Alert Estate

Alerting is where a lot of operational conversations start. What fired overnight? Is this alert still configured the way the runbook says? Why has this service been quiet? Answering these questions has historically meant clicking through the UI app by app, or maintaining a REST script that one person on the team understands.

Splunk MCP server 2.0 adds five read-only alert tools to help tackle these challenges.

Keeping a full inventory across every app used to be a small project. Now, you can turn that project into a single query. When an alert goes quiet, splunk_get_alert_throttle distinguishes actively suppressed from throttle-configured-but-inactive from no throttle at all, with the window duration and time remaining when suppression is on. This can help you discern the difference between "someone silenced this on purpose" and "this is broken."

All five of these tools are read-only. An agent can read your alert estate and reason about it, but it cannot change it.

BYOT: Bring Your Own Tools

As with most apps, built-in tools make for a great starting point. However, you might find yourself in need of something a little more bespoke to meet your team’s needs. Any Splunk app can register its own MCP tools, backed either by an SPL template or by a REST API call routed through splunkd, which means the tools your agents get can match the way your organization actually works.

When it comes to building your own tools, you also have options on how you want to approach the process. You can register them programmatically through the /services/mcp_tools endpoint or create them in the MCP server app's Tools tab with a form-based editor. Create, update, enable, disable, and delete options are available through both paths.

Tools are namespaced by app and must be explicitly enabled before any AI assistant can see them, and registering one requires the mcp_tool_admin capability. Your platform team decides what exists in your environment. Nothing becomes available by accident.

Control Through Governance

All of the capabilities mentioned so far run inside a governance surface that admins configure. All this lines up with the order the questions usually get asked in a security review.

Who Is This? OAuth, on by Default

OAuth became generally available in Splunk Cloud 10.5 and is enabled by default for eligible customers in AWS Cloud regions. You no longer need to file a request for it, per stack. MCP clients such as Claude Code, Codex, Cursor, and MCP Inspector sign in through a browser-based flow. The user then authenticates against Splunk interactively, the client exchanges an authorization code for an access token, and no static credential is stored in the client configuration.

For an admin, that changes three things.

1. Access is tied to a person rather than to a shared secret sitting in a config file.
2. There are no long-lived tokens to distribute, rotate, or chase down when someone changes teams.
3. Revoking a user in Splunk revokes their agent access, because it is the same identity.

What Can They Call, and on Whose Behalf?

Splunk MCP server ships with two capabilities: mcp_tool_execute to use tools and mcp_tool_admin to manage them and create tokens. You can assign them to whichever roles best fit your organization. From version 1.3 onward, admins can also map individual Splunk roles to individual tools via the Access and Governance tab. A role that isn't mapped to a tool can neither see it in the tool list nor call it, and enforcement happens at both points.

Underneath that, tools execute as user that called them. Your existing index and knowledge-object permissions still apply, unchanged. An agent working on behalf of an analyst sees exactly what that analyst sees, which means you are not maintaining a second permission model for agents.

What SPL Is Allowed To Run?

Every query from an MCP client is checked against an allowlist of safe SPL commands. That list used to be fixed, so any gap became an engineering conversation. Now, admins have the option to extend it. The bundled defaults stay immutable, which keeps the baseline consistent between Splunk MCP server and Splunk AI Assistant, but custom commands sit on top and can be added, disabled, or removed. Every user can view and search the full list, so no one has to guess why a query was rejected.

How Much, and for How Long?

Rate limits can now be set globally and on a per tool basis, in fixed one-minute windows. Timeouts cap how long a tool call can run, with separate values for standard MCP server calls and Splunk AI Assistant calls. You can also set the default number of rows returned when a caller doesn't specify one.

These live together under Guardrails, alongside the SPL allow list, and all of them are configurable by admins.

What Are Our Agents Actually Doing?

Searches issued through Splunk MCP server carry a provenance label into _audit. You can query agentic activity with the same searches and the same skills you already use for search auditing, in the index you already look at. This is usually the first question a security team asks, and it has a short answer: it's in _audit, like everything else.

Looking Ahead

A standard protocol is worth more than any single tool in it. Every client above talks to the same server, under the same roles, the same allowlist, and the same audit trail. Adding a new AI client to your environment becomes a configuration decision rather than an integration project and adding a capability to Splunk MCP server makes it available to every client at once.

As we enter our 2.x release series, our team will continue to innovate and improve on the ways that MCP server can help your team make the move to more efficient and effective agentic operations. As always, if you have an idea for a feature or update you’d like to see, please let us know more over at https://ideas.splunk.com.

Happy Splunking!