MCP Server for Splunk

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.

Args: conf_file (str): Configuration file name without .conf extension (e.g., 'props', 'transforms', 'inputs', 'outputs', 'server', 'web') stanza (str, optional): Specific stanza name within the conf file to retrieve. If not provided, returns all stanzas in the file. app (str, optional): Filter results to stanzas owned by this app (namespace). owner (str, optional): Filter results to stanzas owned by this owner (user).

Retrieve comprehensive inventory of all installed Splunk applications including metadata (name, label, version, description, author, visibility status). Use this tool when you need to list all apps in the Splunk environment, such as for auditing, management, or troubleshooting compatibility. This tool requires no arguments.

Returns detailed app catalog with 54+ apps typically found in enterprise environments, including core Splunk apps, add-ons (TAs), custom applications, and third-party integrations.

Retrieve comprehensive inventory of all Splunk users and their properties. Use this tool when you need to list all users in the Splunk environment, such as for security audits, user management, or understanding access patterns. This tool requires no arguments.

Response Format: Returns a dictionary with 'status' field indicating success/error and 'data' containing:

• count: Total number of users found

• users: Array of user objects with username, realname, email, roles, type, and defaultApp

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.

Args: tool_name (str): Name of the tool to enhance (e.g., 'get_configurations', 'list_indexes') generate_examples (bool, optional): Whether to generate parameter examples based on the tool's signature and category. Defaults to True. include_response_format (bool, optional): Whether to analyze and include expected response format information. Defaults to True.

Response Format: Returns a dictionary with 'status' field and 'data' containing:

• tool_name: The analyzed tool's name

• original_description: Original tool description

• enhanced_description: Improved description with details

• analysis: Detailed parameter and format analysis

• recommendations: Suggestions for further 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.

Args: action (str): Management action to perform. Valid options: - 'enable': Activate the application - 'disable': Deactivate the application - 'restart': Disable then enable the application - 'reload': Refresh application configuration app_name (str): Name of the Splunk application to manage. Examples: - 'search': Core Splunk Search app - 'splunk_monitoring_console': Monitoring Console - 'my_custom_app': Custom business applications

Response Format: Returns a dictionary with 'status' field and 'data' containing:

• action: The performed action

• app_name: The target application name

• result: Action-specific status and configuration details

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.

Args: conf_file (str): Configuration file name without .conf (e.g., 'props', 'transforms'). stanza (str): Stanza name to create/update. settings (dict): Key/value settings to apply in the stanza. app (str, optional): App namespace for the config (defaults to 'search' if not provided). owner (str, optional): Owner namespace (defaults to current session user if available). overwrite (bool, optional): Overwrite existing keys if True; otherwise skip them.

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.

Args: count (int, optional): Maximum number of alert groups to return (default: 50) earliest_time (str, optional): Advisory filter for earliest trigger time (default: '-24h@h') latest_time (str, optional): Advisory filter for latest trigger time (default: 'now') search (str, optional): Case-insensitive substring filter applied to alert group name

Outputs: 'triggered_alerts' array, total counts, and the applied parameters. Security: results are constrained by the authenticated user's permissions.

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.

Args: name (str): Dashboard name (required) owner (str, optional): Dashboard owner. Default: 'nobody' app (str, optional): App context. Default: 'search'

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.

Args: owner (str, optional): Filter by owner. Use 'me' for current user's dashboards, 'nobody' for shared dashboards, or a specific username. Default: 'nobody' app (str, optional): Filter by app context. Default: '-' (all apps) count (int, optional): Max results to return. 0=all, default: 50 for performance offset (int, optional): Result offset for pagination. Default: 0 search_filter (str, optional): Filter results (e.g., 'name=security') type_filter (str, optional): Filter by type: 'classic', 'studio', or 'any'. Default: 'any' my_dashboards_only (bool, optional): If True, only return dashboards owned by the current user. Overrides 'owner' parameter. Default: False private_only (bool, optional): If True, only return private dashboards (sharing='user'). Works with any owner filter. Default: False

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

Args: name (str): Dashboard name (required) definition (dict|str): Studio JSON (dict/string) or Classic XML (string) (required) owner (str, optional): Dashboard owner. Default: 'nobody' app (str, optional): App context. Default: 'search' label (str, optional): Human label shown in UI description (str, optional): Dashboard description dashboard_type (str, optional): 'studio'|'classic'|'auto' (default: 'auto') sharing (str, optional): 'user'|'app'|'global' read_perms (list[str], optional): Roles/users granted read write_perms (list[str], optional): Roles/users granted write overwrite (bool, optional): If True, updates existing dashboard of same name

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.

Args: topic (str): Administration topic. Use list_admin_topics() to see all available topics. Common topics include: - 'indexes' - Index management and configuration - 'authentication' - User authentication setup - 'users' - User management and roles - 'apps' - Application management - 'deployment' - Deployment configuration - 'monitoring' - System monitoring setup - 'performance' - Performance optimization - 'security' - Security configuration - 'forwarders' - Forwarder configuration - 'clustering' - Clustering setup version (str, optional): Splunk version for documentation. Examples: - '9.4' - Splunk 9.4 documentation - '9.3' - Splunk 9.3 documentation - 'latest' - Latest version (default) auto_detect_version (bool, optional): Whether to auto-detect Splunk version from connected instance. Defaults to True.

Returns embedded resource with detailed administration guide.

💡 Tip: Use list_admin_topics() to discover all available topics.

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

Args: command (str): SPL command name. Use list_spl_commands() to see common commands. Examples: - 'stats' - Statistical aggregation command - 'eval' - Field calculation and manipulation - 'search' - Search filtering command - 'timechart' - Time-based charting - 'rex' - Regular expression field extraction - 'lookup' - Data enrichment from lookups version (str, optional): Splunk version for documentation. Examples: - '9.4' - Splunk 9.4 documentation - '9.3' - Splunk 9.3 documentation - 'latest' - Latest version (default) auto_detect_version (bool, optional): Whether to auto-detect Splunk version from connected instance. Defaults to True.

Returns embedded resource with detailed SPL command documentation.

💡 Tip: Use list_spl_commands() to see common commands, but this tool supports many more SPL commands beyond the common ones listed.

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.

Args: doc_uri (str): Documentation URI pattern. Use list_available_topics() to see all available URI patterns and topics. Examples: - 'splunk-docs://cheat-sheet' - Splunk SPL cheat sheet - 'splunk-docs://discovery' - Available documentation discovery - 'splunk-docs://9.4/spl-reference/stats' - SPL stats command - 'splunk-docs://latest/troubleshooting/metrics-log' - Troubleshooting guide - 'splunk-docs://9.3/admin/indexes' - Admin guide for indexes - 'splunk-cim://authentication' - CIM data model (latest version) - 'splunk-cim://6.1/network-traffic' - CIM data model (specific version) - 'splunk-cim://discovery' - CIM discovery index - 'dashboard-studio://cheatsheet' - Dashboard Studio cheatsheet - 'dashboard-studio://discovery' - Dashboard Studio discovery - 'splunk-spec://props.conf' - Config file specification auto_detect_version (bool, optional): Whether to auto-detect Splunk version for dynamic resources. Defaults to True.

Returns embedded resource with actual documentation content in markdown format.

💡 Tip: Use list_available_topics() to discover all available URI patterns and topics.

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

Args: topic (str): Troubleshooting topic. Use list_troubleshooting_topics() to see all available topics. Common topics include: - 'metrics-log' - About metrics.log for performance monitoring - 'splunk-logs' - What Splunk logs about itself - 'platform-instrumentation' - Platform instrumentation overview - 'search-problems' - Splunk web and search problems - 'indexing-performance' - Indexing performance issues - 'indexing-delay' - Event indexing delays - 'authentication-timeouts' - Authentication timeout issues version (str, optional): Splunk version for documentation. Examples: - '9.4' - Splunk 9.4 documentation - '9.3' - Splunk 9.3 documentation - 'latest' - Latest version (default) auto_detect_version (bool, optional): Whether to auto-detect Splunk version from connected instance. Defaults to True.

Returns embedded resource with detailed troubleshooting guide.

💡 Tip: Use list_troubleshooting_topics() to discover all available topics.

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.

Args: model (str): CIM data model name. Use list_cim_data_models() to see all available models. Examples: 'authentication', 'network-traffic', 'malware' version (str, optional): CIM version (default: 'latest'). Options: '6.1', '6.0', '5.3', '5.2', '5.1', 'latest'

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

Args: config (str): Configuration file name (with or without .conf extension). Use list_config_files() to see common files. Examples: 'props.conf', 'transforms', 'indexes.conf'

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

Args: topic (str): Documentation topic. Use list_dashboard_studio_topics() to see available topics. Examples: 'cheatsheet', 'definition', 'visualizations', 'configuration', 'datasources', 'framework'

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.

Args: app (str): Target Splunk application where the collection will be created. Examples: - 'search': Default search app - 'my_app': Custom application - 'splunk_monitoring_console': Monitoring console app collection (str): Name for the new collection (alphanumeric and underscores only). Examples: - 'users': User information store - 'configurations': Application settings - 'lookup_table': Data enrichment table fields (list[dict], optional): Field definitions specifying data types and constraints accelerated_fields (dict, optional): Index definitions for faster queries replicated (bool, optional): Whether to replicate across cluster (default: True) create_lookup_definition (bool, optional): Also create a transforms.conf lookup definition (default: False)

Outputs: created collection with name, fields, accelerated_fields, replicated. Security: creation is constrained by app-level permissions.

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.

Args: collection (str): Collection name app (str, optional): App where the collection resides (defaults to current/app context) query (object, optional): MongoDB-style filter object (e.g., {"status": "active"})

Outputs: 'documents' array and 'count'. Security: access and results are constrained by the authenticated user's permissions.

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

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.

Args: owner (str, optional): Filter by owner. Default: 'nobody' (all users) app (str, optional): Filter by app context. Default: '-' (all apps) count (int, optional): Max results to return. 0=all, default: 50 for performance offset (int, optional): Result offset for pagination. Default: 0 search_filter (str, optional): Filter results (e.g., 'filename=*.csv')

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

Args: owner (str, optional): Filter by owner. Default: 'nobody' (all users) app (str, optional): Filter by app context. Default: '-' (all apps) count (int, optional): Max results to return. 0=all, default: 50 for performance offset (int, optional): Result offset for pagination. Default: 0 search_filter (str, optional): Filter results (e.g., 'name=geo')

Retrieve distinct metadata values for a given index to aid query construction. Use this tool when you need to discover which hosts, sourcetypes, or sources are present in an index within a recent time window. This is useful for building targeted searches or validating data availability. Results are constrained by your Splunk permissions.

Args: index (str): Target index to inspect (e.g., 'main', 'security') field (str, optional): Metadata field to list values for. One of 'host', 'sourcetype', or 'source' (default: 'host') earliest_time (str, optional): Search start time (e.g., '-24h@h') (default: '-24h@h') latest_time (str, optional): Search end time (e.g., 'now') (default: 'now') limit (int, optional): Maximum number of distinct values to return (default: 100)

Response Format: Returns a dictionary with 'status' and 'data' containing:

• field: Requested field name

• index: Target index

• values: Array of distinct values (up to 'limit')

• count: Number of values returned

Retrieve all accessible data indexes from the Splunk instance. Use this to discover which indexes you can query when building searches or troubleshooting data availability. Returns customer indexes (excludes internal system indexes like _internal and _audit for readability). Results are constrained by the current user's permissions.

Discover and enumerate all available data sources from the configured Splunk instance using the metadata command. This tool provides a comprehensive inventory of data sources across all indexes, helping with data discovery, troubleshooting, and understanding the data landscape in your Splunk environment. Sources represent the origin points of data such as log files, network streams, databases, and other data inputs.

Use Cases:

• Data discovery and cataloging

• Troubleshooting missing data sources

• Understanding data flow and origins

• Planning data retention and archival

• Security analysis and audit trails

Response Format: Returns a dictionary with 'status' field and 'data' containing:

• sources: Sorted array of all data source paths/identifiers

• count: Total number of unique sources discovered

Discover and enumerate all available sourcetypes from the configured Splunk instance using the metadata command. Sourcetypes define how Splunk interprets and processes different types of data, controlling parsing rules, field extractions, and indexing behavior. This tool returns a comprehensive list of sourcetypes present in your Splunk environment, essential for data modeling and search optimization.

Use Cases:

• Data modeling and CIM compliance

• Understanding data variety and formats

• Troubleshooting parsing and extraction issues

• Planning data preprocessing and transformations

• Security analysis and event correlation

• Building comprehensive search queries

Response Format: Returns a dictionary with 'status' field and 'data' containing:

• sourcetypes: Sorted array of all sourcetype identifiers

• count: Total number of unique sourcetypes discovered

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: results list (capped by max_results), mode used, timing, and job id (if job).\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

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.

Outputs: job id, results (JSON), counts, timing, and job status. Security: results are constrained by the authenticated user's permissions.Args: query (str): The Splunk search query (SPL) to execute. Can be any valid SPL command or pipeline. Supports complex searches with transforming commands, joins, and subsearches. Examples: 'index=* | stats count by sourcetype', 'search error | eval severity=case(...)' earliest_time (str, optional): Search start time in Splunk time format. Examples: '-24h', '-7d@d', '2023-01-01T00:00:00' Default: '-24h' latest_time (str, optional): Search end time in Splunk time format. Examples: 'now', '-1h', '@d', '2023-01-01T23:59:59' Default: 'now'

List saved searches with ownership, schedule, visibility, and permission metadata. Use this to discover available reports/automations and to filter by owner/app/sharing. Results reflect only saved searches the current user can access.

Args: owner (str, optional): Filter by owner name (optional) app (str, optional): Filter by application name (optional) sharing (str, optional): Filter by sharing level (optional) include_disabled (bool, optional): Include disabled saved searches (default: False)

Run a Splunk search and return results immediately (no job created). Use this when you need a quick lookup or small result set (typically under ~30s) such as simple stats, ad‑hoc checks, or previews. Do not use for long‑running or heavy searches—prefer run_splunk_search in those cases.

Outputs: returns up to 'max_results' events or rows with timing and the executed query. Security: results are constrained by the authenticated user's permissions.Args: query (str): The Splunk search query (SPL) to execute. Can be any valid SPL command or pipeline. The 'search' command is automatically prepended if needed. Examples: 'index=main error', '| metadata type=hosts', '| stats count by sourcetype' earliest_time (str, optional): Search start time in Splunk time format. Examples: '-15m', '-1h', '-1d@d', '2023-01-01T00:00:00' Default: '-15m' latest_time (str, optional): Search end time in Splunk time format. Examples: 'now', '-1h', '2023-01-01T23:59:59' Default: 'now' max_results (int, optional): Maximum number of results to return. Higher values may cause longer execution times. Range: 1-10000. Default: 100

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.

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-execute workflows that can be run with workflow_runner or the dynamic agent

Perfect for workflow contributors who need guided assistance in creating well-structured, validated workflows that integrate seamlessly with the dynamic troubleshoot agent.

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.

Execute any available workflow by ID with comprehensive parameter control and parallel execution.

This tool provides a flexible interface to execute both core (built-in) and contrib (user-contributed) workflows with full control over execution parameters and diagnostic context. It leverages the same parallel execution engine used by the dynamic troubleshoot agent for optimal performance.

Core Capabilities:

• Universal Execution: Run any workflow by ID - core or contrib workflows

• Parameter Flexibility: Full control over time ranges, focus areas, and complexity levels

• Parallel Processing: Dependency-aware parallel task execution for optimal performance

• Comprehensive Results: Detailed execution results with performance metrics and summaries

• Progress Tracking: Real-time progress reporting during workflow execution

Key Parameters:

• workflow_id (required): ID of workflow to execute (use list_workflows to discover)

• problem_description (optional): Context about the specific issue being investigated

• earliest_time/latest_time (optional): Time range for diagnostic searches (default: "-24h" to "now")

• focus_index/focus_host/focus_sourcetype (optional): Specific focus areas for targeted analysis

• complexity_level (optional): "basic", "moderate", "advanced" analysis depth (default: "moderate")

• enable_summarization (optional): AI-powered result summarization (default: True)

Supported Workflows:

• Core Workflows: missing_data_troubleshooting, performance_analysis

• Contrib Workflows: Any custom workflows from contrib/workflows/ directory

Benefits:

• Consistent interface for all workflow types

• Optimized parallel execution with dependency management

• Flexible parameter control for different scenarios

• Comprehensive result analysis and reporting

• Integration with existing workflow infrastructure

When to use

• Use when you know the workflow ID to run (discover via list_workflows)

• Use for executing core or contrib workflows with custom time windows and focus context

• Use in automation pipelines that orchestrate troubleshooting by workflow ID

Arguments

• See Key Parameters list above. All are optional except workflow_id.

Outputs

• Detailed execution results, task results, summary, and metadata including execution timing

Perfect for executing specific workflows when you know exactly which diagnostic procedure you need to run, or for building automated troubleshooting pipelines.

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.

Args: trigger_error: If True, triggers a test exception to verify error tracking. test_type: Type of test to run: - "full": Complete test with transaction, spans, and message - "trace": Only create transaction and spans - "error": Only trigger an error - "message": Only send a test message

Returns: Status of the test with details on what was sent

Return request headers and context details for debugging.

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