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.

Retrieve installed Splunk applications including name, label, version, description, author, and visibility. If has_more is true, call again with offset=next_offset.

Retrieve Splunk users and their properties (username, realname, email, roles, type, defaultApp). If has_more is true, call again with offset=next_offset.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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

Get detailed Splunk administration documentation for specific topics. Returns comprehensive administration guides with configuration, management, and best practices as an embedded resource.

Get detailed reference documentation for specific SPL (Search Processing Language) commands. Returns comprehensive documentation with syntax, examples, and usage patterns as an embedded resource.

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

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.

Get detailed Splunk troubleshooting documentation for specific topics. Returns comprehensive troubleshooting guides with diagnostics, solutions, and best practices as an embedded resource.

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.

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.

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.

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.

Get detailed Splunk CIM data model documentation with field specifications and configuration examples. Returns comprehensive reference including field mappings, tagging requirements, and implementation guidance.

Get detailed Splunk configuration file specification documentation. Returns comprehensive reference with all configuration options, syntax, and examples.

Get Dashboard Studio documentation for a specific topic. Returns comprehensive documentation with examples, schema details, and best practices.

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.

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.

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.

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'.

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.

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.

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)

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.

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 '.

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.

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.

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.

Discover sourcetypes using the metadata command. Large environments are paged. If has_more is true, call again with offset=next_offset.

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.

Delete a saved search with confirmation and safety checks

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Output Formats:

• 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.)

Workflow Sources:

• Core Workflows: Built-in system workflows (missing_data_troubleshooting, performance_analysis)

• Contrib Workflows: User-contributed workflows from contrib/workflows/ directory

Key Information Provided:

• 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

When to use

• 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

Arguments

• 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")

Outputs

• 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.

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.

Modes:

• 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

Key Capabilities:

• 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

Validation Features:

• Schema compliance verification

• Circular dependency detection

• Tool availability checking

• Context variable validation

• Integration compatibility assessment

When to use

• 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)

Arguments

• 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"

Outputs

• 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.

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.

Output Formats:

• 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

Key Information Provided:

• 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

When to use

• 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

Arguments

• format_type (optional): "detailed" (default), "schema", "quick", or "examples"

Outputs

• 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.

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.

Return request headers and context details for debugging.

Includes all HTTP headers (with sensitive values masked) and core context metadata.