This MCP server lets MCP-compatible AI assistants and agents search, explore, administer, and document Splunk through MCP tools, resources, and prompts.
Run SPL searches as one-shot or tracked jobs, poll job status, inspect errors, and page results.
List, inspect, create, update, delete, and execute saved searches.
Manage alerts: list alert actions and triggered alerts, and create/update/delete alerts with schedules, thresholds, and actions.
Discover Splunk data: indexes, sourcetypes, sources, hosts, and metadata values.
List dashboards, retrieve raw definitions, and create Simple XML or Dashboard Studio dashboards.
Work with KV Store collections and lookups: list/query/create collections, list lookup files and definitions.
Perform admin tasks: list apps/users/current user, enable/disable/restart/reload apps, read/create config stanzas, and check Splunk health.
Access built-in documentation: SPL references, CIM models, config specs, admin/troubleshooting guides, Dashboard Studio docs, and docs by URI.
Discover, build, validate, and inspect troubleshooting workflows.
Debug integrations with Sentry test and user-agent info tools, and improve tool descriptions.
Run over stdio or Streamable HTTP, with per-request Splunk credentials in HTTP mode; write actions remain constrained by Splunk permissions.
Enables AI agents to interact with Splunk Enterprise/Cloud environments, providing comprehensive tools for search and analytics, data discovery, administration, health monitoring, and AI-powered troubleshooting workflows. Includes capabilities for natural language to SPL conversion, real-time search management, metadata exploration, user and app management, system health monitoring, and automated diagnostic procedures.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server for Splunk show me the top 5 error sources from the last hour"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An open-source Splunk MCP server (Model Context Protocol) that lets AI assistants and agents search, explore and manage Splunk Enterprise and Splunk Cloud Platform.
Python integrations: see the package namespace migration guide.
mcp-for-splunk exposes Splunk's REST API as MCP tools, resources and prompts. Any MCP-compatible client, such as Cursor, Claude Desktop, VS Code or your own agent, can run SPL, discover indexes and sourcetypes, read configuration, manage saved searches, alerts, dashboards and KV Store, and look up Splunk and CIM documentation. It runs over stdio or Streamable HTTP. In HTTP mode, each request can carry its own Splunk credentials in headers, so one server can serve several users or Splunk environments.
📖 Setup guide and tools reference: deslicer.ai/docs/integrations/splunk-mcp
⚖️ How it compares with Splunk's own MCP Server app: deslicer.ai/compare/splunk-mcp-server
📦 PyPI: mcp-server-for-splunk · ITSI companion: mcp-itsi-server
Looking for Splunk's vendor-supported MCP server? That's the Splunk MCP Server app on Splunkbase (app 7931), which runs inside Splunk at
/services/mcp. This project is a separate, community-maintained server that runs outside Splunk and talks to the management port (8089).
Related MCP server: Splunk MCP for SOC Operations
Requirements: Python 3.11+ (Python 3.10 is no longer supported), uv or pip, and a Splunk Enterprise or Splunk Cloud Platform instance with REST API (port 8089) access. Docker is optional.
pip install mcp-server-for-splunk # or: uv tool install mcp-server-for-splunk
export SPLUNK_HOST=your-splunk.example.com
export SPLUNK_PORT=8089
export SPLUNK_TOKEN=<splunk-bearer-token> # or SPLUNK_USERNAME + SPLUNK_PASSWORD
mcp-server --transport stdio # for desktop clients that spawn the server
mcp-server # Streamable HTTP on http://localhost:8001/mcp/The installed mcp-server command accepts --transport {http,stdio}, --host and --port. The HTTP port defaults to MCP_SERVER_PORT or 8001.
git clone https://github.com/deslicer/mcp-for-splunk.git
cd mcp-for-splunk
cp env.example .env # then edit the Splunk settings
./scripts/smart-install.sh --dry-run # macOS/Linux: preview missing prerequisites
./scripts/smart-install.sh # install them (Python, uv, Git, Node)
uv run mcp-server --local --detached # start the server (checkout default port 8003)
uv run mcp-server --test # verify; add --detailed for tools/resources
uv run mcp-server --stop # stop this project's servicesOn Windows, use the same uv run mcp-server … commands from PowerShell (see scripts/build_and_run.ps1 and the Windows guide). In a checkout, mcp-server asks whether to run the full Docker stack or a local process. The local endpoint is http://localhost:8003/mcp/.
Copy env.example to .env. The main variables:
Variable | Purpose | Default |
| Splunk management endpoint |
|
|
| |
| Bearer token; takes precedence over username/password | |
| Basic credentials | |
| Existing splunkd session token (advanced) | |
| TLS verification. The client defaults to |
|
| Used to build links to dashboards and jobs | |
| HTTP bind address |
|
| Stateless HTTP and JSON responses for wider client compatibility |
|
| Toolsets for clients that send no |
|
| How long |
|
| Inbound MCP authentication | |
| Log level |
|
For stdio clients, you can also pass MCP_SPLUNK_HOST, MCP_SPLUNK_PORT, MCP_SPLUNK_USERNAME, MCP_SPLUNK_PASSWORD, MCP_SPLUNK_TOKEN, MCP_SPLUNK_SCHEME and MCP_SPLUNK_VERIFY_SSL in the client's env block.
{
"mcpServers": {
"splunk": {
"command": "mcp-server",
"args": ["--transport", "stdio"],
"env": {
"MCP_SPLUNK_HOST": "your-splunk.example.com",
"MCP_SPLUNK_PORT": "8089",
"MCP_SPLUNK_TOKEN": "<splunk-bearer-token>",
"MCP_SPLUNK_VERIFY_SSL": "true"
}
}
}
}Start the server once, then let each client send its own Splunk target in headers:
{
"mcpServers": {
"splunk-http": {
"url": "http://localhost:8001/mcp/",
"headers": {
"X-Splunk-Host": "your-splunk.example.com",
"X-Splunk-Port": "8089",
"X-Splunk-Scheme": "https",
"X-Splunk-Token": "<splunk-bearer-token>",
"X-Splunk-Verify-SSL": "true"
}
}
}
}Supported headers: X-Splunk-Host, X-Splunk-Port, X-Splunk-Scheme, X-Splunk-Token, X-Splunk-Username, X-Splunk-Password, X-Splunk-Session-Token, X-Splunk-Verify-SSL, X-Splunk-Web-Url, X-Splunk-Web-Port, X-Splunk-Web-Locale, X-MCP-Toolsets. Sessionless mode is the default. Send a stable X-Session-ID if you want config cached across requests. See HTTP client connection modes. If you run from a checkout, use port 8003.
The core server registers these tools (source: src/mcp_server_for_splunk/tools/). Tools that write to Splunk are marked ✏️. Your Splunk role's permissions still apply.
Area | Tool | What it does |
Search |
| Run SPL and wait up to |
| Run SPL as a tracked job with progress and stats | |
| Status, properties and messages for a job (sid) | |
| One page of results from a completed job | |
Saved searches |
| Saved searches with owner, schedule and permissions |
| Full configuration of one saved search | |
| Run a saved search by name | |
| Create a saved search, optionally scheduled | |
| Update query, schedule or sharing | |
| Delete a saved search (with confirmation) | |
Alerts |
| Fired alerts and details |
| Installed alert actions, including custom ones | |
| Manage alerts (scheduled saved searches with triggers) | |
Metadata |
| Accessible indexes |
| Sourcetypes via | |
| Sources via | |
| Distinct metadata values for an index | |
Dashboards |
| Simple XML and Dashboard Studio dashboards |
| Raw definition of a dashboard | |
| Create a Simple XML or Dashboard Studio dashboard | |
KV Store |
| Collections and schema |
| Query documents with filters | |
| Create a collection | |
Lookups |
| CSV lookup files |
| Lookup definitions (transforms) | |
Admin |
| Installed apps |
| Enable, disable or restart apps | |
| Users and roles | |
| The authenticated user | |
| Read settings from | |
| Create or update a stanza in a | |
| Connectivity and health status | |
| Developer helper that improves tool descriptions | |
Docs and CIM |
| CIM data models and field specifications |
| SPL reference | |
|
| |
| Admin documentation | |
| Troubleshooting documentation | |
| Dashboard Studio documentation | |
| Discover and fetch Splunk docs by URI | |
Workflows |
| Discover, author and validate troubleshooting workflow JSON |
Workflow JSON definitions are for discovery, validation and external orchestration. The built-in workflow_runner was removed with the move to FastMCP 4 / MCP SDK v2. See the workflows guide and the tools reference.
Resources: Splunk documentation (splunk-docs://…, including SPL reference, troubleshooting and admin topics), configuration specs (splunk-spec://{config}), CIM data models, Dashboard Studio docs and embedded docs. See docs/reference/resources.md.
Prompts: mcp_overview, workflow_creation_guide, tool_usage_guide.
llms.txt: a guide for LLMs on using this server.
A server for Splunk IT Service Intelligence lives in mcp_itsi/ and is published as mcp-itsi-server. Run it as a plugin of this server (pip install "mcp-server-for-splunk[itsi]", enabled per client with X-MCP-Toolsets: splunk,itsi or MCP_DEFAULT_TOOLSETS) or standalone (pip install mcp-itsi-server). It uses the same X-Splunk-* headers. See the ITSI getting started guide.
docker-compose.yml runs the MCP server behind Traefik on http://localhost:8003/mcp, together with the MCP Inspector. docker-compose-splunk.yml adds a Splunk container (so1) for local testing; bring your own Splunk license if you need one. See the deployment guide.
pip install "mcp-server-for-splunk[sentry]" and set SENTRY_DSN. See Sentry monitoring.
pip install "mcp-server-for-splunk[otel]" and set OTEL_EXPORTER_OTLP_ENDPOINT. See OpenTelemetry tracing.
uv run generate-tool # scaffold a new tool
uv run validate-tools # validate tool implementationsSee CONTRIBUTING.md, contrib/README.md, AGENTS.md, the Code of Conduct, the Security policy and Governance. Questions and bugs go to GitHub Issues.
Maintained by Deslicer. Deslicer uses this server in its product, where it's documented at deslicer.ai/docs/integrations/splunk-mcp. Splunk is a trademark of Splunk LLC; this project is not affiliated with or endorsed by Splunk.
Create a Splunk alert (a scheduled saved search with trigger conditions). Actions can be any installed alert action, including custom ones, and more than one action is allowed. Call list_alert_actions first for custom action names and param keys.
Inputs: name (required), search (required), cron_schedule (required), app, +13 more.
Creates or updates a stanza in a Splunk .conf file at the app level. Uses REST first, with SDK fallback. Defaults to the current session owner and app 'search' when not provided. Will only overwrite existing keys when overwrite=true; otherwise, only new keys are added.
Inputs: stanza (required), settings (required), conf_file (required), app, +2 more.
Create a new dashboard in Splunk. Accepts Classic Simple XML (string) or Dashboard Studio JSON (object/string) via eai:data. Optionally overwrite if it exists and set sharing/permissions (ACL).
Inputs: name (required), definition (required), app, label, +8 more.
Create a KV Store collection with optional fields and indexing. Use this to provision a new collection for lookups or persisted configuration in a specific app.
Inputs: app (required), collection (required), fields, replicated, +2 more.
Create a saved search (report/automation) with optional scheduling and sharing. Use this to persist useful SPL queries and optionally schedule them via cron.\n\nOutputs: creation status and the applied configuration.\nSecurity: visibility and execution are constrained by permissions and chosen sharing level.
Inputs: name (required), search (required), app, sharing, +6 more.
Delete a Splunk alert. Alerts are saved searches, so this removes that saved search. Requires confirm=true. Use app and owner when the name exists in more than one namespace.
Inputs: name (required), app, owner, confirm.
Delete a saved search with confirmation and safety checks
Inputs: name (required), app, owner, confirm.
Discover all available Splunk documentation resources with examples and usage patterns. Returns a comprehensive guide showing available documentation types, URI patterns, and quick access links. Perfect for understanding what documentation is available and how to access it through the documentation tools.
Returns embedded resource with discovery guide including:
Static documentation resources (cheat sheet, etc.)
Dynamic documentation patterns (SPL reference, troubleshooting, admin guides)
Version support information
Quick access examples for common documentation needs
Usage patterns for agentic frameworks
Inputs: no named parameters.
Analyzes existing MCP tools and enhances their descriptions with detailed argument definitions, parameter examples, and usage patterns. Use this tool when you need to improve or generate better documentation for a tool, such as adding examples or clarifying parameters. This tool examines the current tool's metadata, inspects its execute method signature, and generates comprehensive documentation improvements.
Inputs: tool_name (required), generate_examples, include_response_format.
Run a saved search by name with optional time overrides and mode selection. Use this to execute existing reports/automations quickly. Choose 'oneshot' for immediate results or 'job' for progress tracking and large result sets.\n\nOutputs: first result page, paging fields, job_id, and Splunk Web job links. If has_more is true, call get_search_job_results with job_id and offset=next_offset.\nSecurity: execution and results are constrained by the authenticated user's permissions.
Inputs: name (required), app, mode, owner, +3 more.
Get detailed Splunk administration documentation for specific topics. Returns comprehensive administration guides with configuration, management, and best practices as an embedded resource.
Inputs: topic (required), version, auto_detect_version.
Get detailed Splunk CIM data model documentation with field specifications and configuration examples. Returns comprehensive reference including field mappings, tagging requirements, and implementation guidance.
Inputs: model (required), version.
Get detailed Splunk configuration file specification documentation. Returns comprehensive reference with all configuration options, syntax, and examples.
Inputs: config (required).
Retrieves Splunk configuration settings from specified .conf files. Use this tool when you need to access or inspect Splunk configurations, such as for troubleshooting, auditing, or understanding settings in files like props.conf or inputs.conf. Access settings from any Splunk configuration file (props.conf, transforms.conf, inputs.conf, outputs.conf, etc.) either by entire file or specific stanza. Returns structured configuration data showing all settings and their values.
Inputs: conf_file (required), app, owner, stanza.
Get the raw definition of a specific dashboard. Returns the complete dashboard source (Simple XML or Dashboard Studio JSON), type, app context, owner, and Splunk Web viewing URL.
Inputs: name (required), app, owner.
Retrieve executed workflows for the current session. If 'id' is provided, returns that single record (if it belongs to this session). If 'workflow_id' is provided, filters the list to that workflow. Otherwise returns a paginated list of latest results per workflow for this session.
Inputs: id, limit, offset, workflow_id.
Get documents from a KV Store collection with optional MongoDB-style query filtering. Use this to fetch lookup/configuration data or narrow results by field values.
Inputs: collection (required), app, query.
Retrieve distinct metadata values for a given index to aid query construction. Use this when you need hosts, sourcetypes, or sources in an index. If has_more is true, call again with offset=next_offset.
Inputs: index (required), field, limit, offset, +2 more.
Get comprehensive details about a specific saved search including configuration, metadata, scheduling, permissions, and alert actions. Returns detailed information about saved search properties, execution settings, and access control configuration. Essential for troubleshooting, auditing, and understanding saved search configurations.\n\nArgs:\n name (str): Name of the saved search to inspect (required)\n app (str, optional): Application context for saved search lookup\n owner (str, optional): Owner context for saved search lookup\n\nResponse Format:\nReturns dictionary with 'status', 'name', 'details', and 'retrieved_at' fields. The 'details' field contains comprehensive nested information including:\n- basic_info: Name, description, search query, visibility\n- scheduling: Schedule configuration and timing\n- dispatch: Time range and execution settings\n- permissions: Access control and sharing settings\n- actions: Email, script, and other alert actions\n- alert: Alert conditions and suppression settings\n- metadata: Creation timestamps and authorship
Inputs: name (required), app, owner.
Get status/properties/messages for a Splunk search job by job id (sid). Use this after run_splunk_search returns a job_id when you want to poll progress or inspect errors without re-running the search.
Inputs: job_id (required), include_raw_content.
Fetch one page of results from a completed Splunk search job. Use after run_oneshot_search, run_splunk_search, or execute_saved_search when has_more is true. Pass job_id and offset=next_offset.
Inputs: job_id (required), count, offset.
Get detailed reference documentation for specific SPL (Search Processing Language) commands. Returns comprehensive documentation with syntax, examples, and usage patterns as an embedded resource.
Inputs: command (required), version, auto_detect_version.
Get the comprehensive Splunk SPL cheat sheet with commands, regex patterns, and usage examples. Returns the complete cheat sheet as an embedded resource with actual markdown content, perfect for quick reference during SPL query development and troubleshooting.
Returns embedded resource with complete SPL reference content including:
Core SPL commands and syntax
Regular expression patterns
Statistical functions
Time modifiers and formatting
Search optimization tips
Common use cases and examples
Inputs: no named parameters.
Retrieve any Splunk documentation by URI pattern. This tool wraps existing documentation resources and returns embedded resources with actual content, making them compatible with agentic frameworks that don't support MCP resources natively. Supports all documentation types including cheat sheets, troubleshooting guides, SPL references, and admin guides.
Inputs: doc_uri (required), auto_detect_version.
Check Splunk server connectivity and return comprehensive health status information including server version, connection status, and system information. Supports both server-configured connections and custom connection parameters for testing different Splunk instances. Essential for connectivity troubleshooting and server validation.\n\nArgs:\n splunk_host (str, optional): Splunk server hostname or IP address (e.g., 'localhost', 'splunk.example.com', '10.1.1.100')\n splunk_port (int, optional): Splunk management port, typically 8089 (e.g., 8089, 8000, 9997)\n splunk_username (str, optional): Splunk username for authentication (e.g., 'admin', 'splunk', 'analyst')\n splunk_password (str, optional): Splunk password for authentication\n splunk_scheme (str, optional): Connection scheme - 'http' or 'https'\n splunk_verify_ssl (bool, optional): Whether to verify SSL certificates\n\nNote: If connection parameters are not provided, uses the server's configured connection.\n\nResponse Format:\nReturns dictionary with 'status', 'version', 'server_name', and 'connection_source' fields. Status can be 'connected' or 'error'.
Inputs: splunk_host, splunk_port, splunk_scheme, splunk_password, +2 more.
Get Dashboard Studio documentation for a specific topic. Returns comprehensive documentation with examples, schema details, and best practices.
Inputs: topic (required), version.
Get detailed Splunk troubleshooting documentation for specific topics. Returns comprehensive troubleshooting guides with diagnostics, solutions, and best practices as an embedded resource.
Inputs: topic (required), version, auto_detect_version.
List all available admin guide topics with descriptions. Returns a structured list of administration topics that can be used with the get_admin_guide tool. Each topic includes:
Topic key for use in API calls
Description of what the topic covers
Example usage
Use this tool to discover what admin documentation is available before calling get_admin_guide with specific topics.
Inputs: no named parameters.
List alert actions installed on the connected Splunk instance, including custom actions. Returns name, label, description, is_custom, app, and param_keys. Call this before create_alert or update_alert when using a custom action so you pass the correct action name and param keys.
Outputs: 'alert_actions' array and 'count'. Security: results are constrained by the authenticated user's permissions.
Inputs: no named parameters.
Retrieve installed Splunk applications including name, label, version, description, author, and visibility. If has_more is true, call again with offset=next_offset.
Inputs: count, offset, search_filter.
List all available documentation topics and URI patterns for discovery. This tool helps LLMs and agentic frameworks understand what documentation topics are available across different categories:
Returns structured information about:
Available troubleshooting topics with descriptions
Available admin guide topics
Common SPL commands with examples
URI patterns for accessing documentation
Version support information
Use this tool first to discover what documentation is available before requesting specific topics.
Inputs: no named parameters.
List all available Splunk Common Information Model (CIM) data models. Returns structured information about all 26 CIM data models including name, description, use cases, required tags, and deprecation status. Use this to discover what CIM models are available before calling get_cim_reference.
Inputs: no named parameters.
List common Splunk configuration files (.conf) with descriptions. Returns structured information about configuration files that can be used with get_config_spec() to retrieve detailed specification documentation.
Inputs: no named parameters.
List dashboards in Splunk (Simple XML and Dashboard Studio). Returns metadata including name, label, type (classic/studio), app, owner, permissions, sharing level, last updated, and Splunk Web viewing URLs.
Inputs: app, count, owner, offset, +4 more.
List all available Dashboard Studio documentation topics. Returns structured information about available topics including cheatsheet, definition schema, visualizations guide, and configuration options. Use this to discover what Dashboard Studio documentation is available.
Inputs: no named parameters.
Retrieve accessible data indexes from the Splunk instance. Use this to discover which indexes you can query when building searches. Excludes internal indexes (name starts with _) unless include_internal is true. If has_more is true, call again with offset=next_offset.
Inputs: count, offset, search_filter, include_internal.
List KV Store collections with basic schema details. Use this to discover available KV stores for lookups, configuration, or caching, optionally filtering by app.
Outputs: array of collections with name, fields, accelerated_fields, replicated; and total count. Security: results are constrained by the authenticated user's permissions.Args: app (str, optional): Optional app name to filter collections count (int, optional): Page size. Default 50. Maximum 200. Values above 200 are capped to 200; 0 uses 50. Do not send a count larger than 200. offset (int, optional): Result offset (default 0)
Inputs: app, count, offset.
List lookup definitions (transforms) in Splunk. Returns metadata including name, type, associated filename, fields configuration, app, owner, and permissions. Lookup definitions specify how CSV files or external lookups are used in searches.
Inputs: app, count, owner, offset, +1 more.
List CSV lookup table files in Splunk. Returns metadata including name, filename, app, owner, sharing/permissions, and last updated time. Use this to discover available lookup files. To view the actual CSV content, use run_splunk_search with '| inputlookup '.
Inputs: app, count, owner, offset, +1 more.
List saved searches with ownership, schedule, visibility, and permission metadata. If has_more is true, call again with offset=next_offset. Full SPL is truncated to 200 characters; use get_saved_search_details for the complete search.
Inputs: app, count, owner, offset, +3 more.
Discover data sources using the metadata command. Sources can be numerous; results are paged. If has_more is true, call again with offset=next_offset.
Inputs: count, index, offset.
Discover sourcetypes using the metadata command. Large environments are paged. If has_more is true, call again with offset=next_offset.
Inputs: count, index, offset.
List common SPL (Search Processing Language) commands with descriptions. Returns a structured list of SPL commands that can be used with the get_spl_reference tool. Each command includes:
Command name for use in API calls
Description of what the command does
Example usage
Note: This list includes the most common commands, but get_spl_reference supports many more SPL commands beyond those listed here.
Inputs: no named parameters.
List fired alerts and their details. Use this to review recent triggered alerts, including saved search name, trigger time, owner/app, and trigger reason. Supports a name filter and a max results cap. Note: Splunk's fired alerts feed may not strictly filter by time; earliest/latest are advisory.
Inputs: count, search, latest_time, earliest_time.
List all available troubleshooting topics with descriptions. Returns a structured list of troubleshooting topics that can be used with the get_troubleshooting_guide tool. Each topic includes:
Topic key for use in API calls
Human-readable title
Description of what the topic covers
Example usage
Use this tool to discover what troubleshooting documentation is available before calling get_troubleshooting_guide with specific topics.
Inputs: no named parameters.
Retrieve Splunk users and their properties (username, realname, email, roles, type, defaultApp). If has_more is true, call again with offset=next_offset.
Inputs: count, offset, search_filter.
List all available workflows from core and contrib sources.
This tool provides a comprehensive listing of troubleshooting workflows available in the MCP Server for Splunk system. It discovers and lists both built-in core workflows and user-contributed workflows from the contrib directory.
detailed: Complete workflow information with descriptions and metadata (default)
summary: Brief overview with workflow IDs, names, and basic statistics
ids_only: Simple list of workflow IDs for programmatic use
by_category: Workflows organized by category (security, performance, etc.)
Core Workflows: Built-in system workflows (missing_data_troubleshooting, performance_analysis)
Contrib Workflows: User-contributed workflows from contrib/workflows/ directory
Workflow ID and human-readable name
Description and purpose of each workflow
Number of tasks and dependency information
Source (core vs contrib) and validation status
Category and organizational information
Integration instructions for dynamic troubleshoot agent
Use when you need to discover which workflows exist before running one
Use to filter by category or get just workflow IDs for programmatic selection
format_type (optional): "detailed" (default), "summary", "ids_only", or "by_category"
include_core (optional): Include built-in workflows (default: true)
include_contrib (optional): Include contrib workflows (default: true)
category_filter (optional): Filter by category (e.g., "security", "performance")
Workflow listings in the requested format, discovery metadata, and category summaries
Note: Only workflows available in this server are listed (core + any contrib present)
Perfect for discovering available troubleshooting capabilities and selecting the right workflow for specific Splunk problems.
Inputs: format_type, include_core, category_filter, include_contrib.
Manage Splunk application lifecycle operations including enable, disable, restart, and reload actions. Use this tool when you need to change the state of a Splunk app, such as enabling a disabled app, restarting for configuration changes, or troubleshooting issues. This tool provides essential app management capabilities for maintaining Splunk environments, troubleshooting app issues, and controlling app availability. Operations affect app state and may require Splunk restart for some changes to take effect.
Inputs: action (required), app_name (required).
Retrieve information about the currently authenticated Splunk user. Use this tool whenever you need to check the current user's details, permissions, roles, or capabilities, such as for debugging access issues, understanding available actions, or verifying user context in Splunk environments. This tool requires no arguments.
Response Format: Returns a dictionary with 'status' field indicating success/error and 'data' containing:
username: Current authenticated username
realname: Full display name
email: Email address
roles: Array of assigned role names
type: User type (e.g., 'Splunk')
defaultApp: Default application for the user
capabilities: Array of capabilities granted through roles
Inputs: no named parameters.
Run a Splunk search, wait for completion, and return one page of results. A job is kept so later pages can be fetched with get_search_job_results. Prefer run_splunk_search for long-running queries.
If has_more is true, call get_search_job_results with job_id and offset=next_offset.
Inputs: query (required), count, offset, latest_time, +2 more.
Run a Splunk search as a tracked job with progress and stats. Use this for complex or long‑running queries (joins, transforms, large scans) where you need job status, scan/event counts, and reliable result retrieval. Prefer this over oneshot when the query may exceed ~30s or requires progress visibility.
Waits up to MCP_SEARCH_WAIT_SECONDS (default 15) then returns job_id even if the job is still running. If is_done is false, poll get_search_job_info, then get_search_job_results. If has_more is true after completion, page with offset=next_offset. count/max_results of 0 is treated as the default page size (50), max 100. Security: results are constrained by the authenticated user's permissions.
Inputs: query (required), count, offset, latest_time, +2 more.
Test Sentry integration by sending traces, spans, and optionally errors.
This tool creates a complete transaction with nested spans to verify that tracing is working correctly in your Sentry dashboard.
Inputs: test_type, trigger_error. Returns: object
Update an existing Splunk alert (a scheduled saved search with trigger conditions and optional actions). Omit any field you do not want to change. Search, schedule, trigger, and tracking fields are always patched.
actions_mode (only applies when actions is sent): patch (default): Change only the listed actions and params. Other actions and unspecified params on those actions stay as they are. Use this to change one setting (for example only email.to). Set enabled=false on an action to turn that action off without touching the others. override: The actions list becomes the full set. Listed actions are enabled with the given params; any action currently on the alert but missing from the list is disabled. Use this when you want the alert to have exactly these actions.
Call list_alert_actions first for custom actions and their param names.
Inputs: name (required), app, owner, search, +14 more.
Update an existing saved search's configuration including query, scheduling, and other properties. Allows selective modification of saved search parameters while preserving unchanged settings. Supports updating search logic, time ranges, scheduling configuration, and visibility settings for flexible search management.\n\nArgs:\n name (str): Name of the saved search to update (required)\n search (str, optional): New SPL search query\n description (str, optional): New description text\n earliest_time (str, optional): New default earliest time (e.g., '-24h@h', '-7d', '2024-01-01T00:00:00')\n latest_time (str, optional): New default latest time (e.g., 'now', '@d', '2024-01-02T00:00:00')\n is_scheduled (bool, optional): Enable or disable scheduled execution\n cron_schedule (str, optional): New cron expression for scheduling\n is_visible (bool, optional): Show or hide in Splunk UI\n app (str, optional): Application context for saved search lookup\n owner (str, optional): Owner context for saved search lookup\n\nResponse Format:\nReturns dictionary with 'status', 'name', 'updated', 'changes_made', and 'updated_at' fields.
Inputs: name (required), app, owner, search, +6 more.
Return request headers and context details for debugging.
Includes all HTTP headers (with sensitive values masked) and core context metadata.
Inputs: no named parameters. Returns: result
Interactive tool for creating, editing, and validating custom workflows.
This tool provides comprehensive workflow development capabilities for creating custom troubleshooting workflows that integrate with the MCP Server for Splunk dynamic troubleshooting system. It supports multiple modes of operation to accommodate different workflow development needs.
create: Interactive workflow creation with guided prompts
edit: Modify existing workflow definitions with validation
validate: Comprehensive validation of workflow structure and dependencies
template: Generate pre-built workflow templates for common use cases
process: Process and validate finished workflow definitions
Step-by-step workflow creation with validation
Template generation for common workflow patterns
Comprehensive validation including dependency analysis
JSON output generation with proper formatting
Integration testing and compatibility verification
Processing of complete workflow definitions
Schema compliance verification
Circular dependency detection
Tool availability checking
Context variable validation
Integration compatibility assessment
Use to create new workflows from templates or from scratch
Use to edit or validate an existing workflow JSON before contributing or running it
Use to generate templates and examples for standard categories (security, performance, data quality)
mode (optional): "create", "edit", "validate", "template", or "process" (default: "create")
workflow_data (optional): JSON string or object when editing/validating/processing
template_type (optional): Template key when mode="template" (e.g., "minimal", "security")
file_path (optional): Path to workflow file when mode="validate"
Structured results including validation summaries, templates, or processed workflow data
Ready-to-validate workflow JSON for discovery via list_workflows
Perfect for workflow contributors who need guided assistance in creating well-structured, validated workflows for contrib or core catalogs.
Inputs: mode, file_path, template_type, workflow_data.
Get comprehensive requirements and schema information for creating custom workflows.
This tool provides detailed documentation for creating custom troubleshooting workflows that integrate with the MCP Server for Splunk dynamic troubleshooting system. It includes complete schema definitions, available tools, context variables, validation rules, and integration guidelines.
detailed: Complete requirements with examples and explanations (default)
schema: JSON schema definitions for validation tools
quick: Quick reference for experienced contributors
examples: Example workflow structures and common patterns
WorkflowDefinition and TaskDefinition schema structures
Complete list of available Splunk tools with descriptions
Context variables and their usage patterns
Validation rules and constraints
Integration points with dynamic troubleshoot agent
Best practices for workflow design and task creation
Use at the beginning of authoring to understand schemas and constraints
Use during development for quick reference to context variables and available tools
Use in CI/validation tooling to fetch schemas for automated checks
format_type (optional): "detailed" (default), "schema", "quick", or "examples"
Full schema and best practices (detailed), just schemas (schema), quick cheat sheet (quick), or examples
Perfect for workflow contributors who need to understand the requirements and structure for creating custom diagnostic workflows.
Inputs: format_type.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 57 tools
There are large clusters of near-overlapping tools, especially around documentation (discover_splunk_docs, list_available_topics, get_splunk_documentation, list_admin_topics/get_admin_guide, list_troubleshooting_topics/get_troubleshooting_guide) and workflow management (list_workflows, workflow_builder, workflow_requirements, get_executed_workflows). Search execution also has three similar entry points (run_splunk_search, run_oneshot_search, execute_saved_search), making tool selection error-prone.
Most tools follow a clear list/get/create/update/delete/run prefix pattern with snake_case, so the overall convention is predictable. Minor deviations like 'me', 'workflow_builder', 'workflow_requirements', 'sentry_test', and 'user_agent_info' break the verb_noun pattern but are a small minority.
With 57 tools, this server is far beyond the 16-25 heavy range and crosses the 50+ extreme threshold. The sheer number makes discovery and selection difficult, especially when many tools serve documentation or workflow meta-purposes rather than core Splunk operations.
Search, saved search, and alert lifecycles are well covered, but other claimed areas are incomplete: dashboards can be created/list/retrieved but not deleted, KV store collections can be created/list/read but not written to or deleted, and lookups, indexes, and users are mostly read-only. These gaps will cause agent dead ends in administrative workflows.
Agent-native security, trust, reliability, data and procurement tools for AI workflows.
Autonomous and governed SRE & MLOps control plane for AI agent platforms.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
