Loading ToolBench
MCP Server for Splunk - enables AI assistants to interact with Splunk REST API for log analysis and troubleshooting
The Splunk MCP server has four well-named, read-only tools with complete input schemas and descriptions. Tool names follow verb_noun convention (splunk_search, splunk_list_indexes, splunk_list_sourcetypes, splunk_sample_events), which is excellent for LLM intent inference. All tools have descriptions exceeding 100 characters, and all parameters include type and description fields. However, output schemas are NOT documented, the source shows parameter validation but no return type specification. Error handling is basic (McpError wrapping with ErrorCode.InternalError). No pagination guidance for potentially large result sets. Parameter descriptions could be more actionable (e.g., the 'filter' param in splunk_list_indexes lacks guidance on regex syntax and valid characters). Missing tool annotations (readOnlyHint, idempotentHint) that would clarify intent to the LLM. The server demonstrates competent definitions but lacks the polish and completeness expected of A-tier tools.
List all available Splunk indexes that can be searched. This tool helps you discover what data sources are available in Splunk. Indexes are the top-level organization of data in Splunk - each index contains events from specific data sources. Use this tool to: - Discover available indexes before searching - Find the right index for your query - See index statistics (event count, size, etc.)
List available sourcetypes in Splunk, optionally filtered to a specific index. Sourcetypes classify the format and structure of data in Splunk (e.g., "access_combined", "syslog", "WinEventLog"). Use this tool to: - Discover what types of data exist in an index - Find the right sourcetype for targeted searches - Understand data sources before querying
Retrieve sample events from a Splunk index or sourcetype to understand data structure and field names. This is useful for exploring an unknown index before writing targeted SPL queries. Use this tool to: - Understand what fields are available in an index - See the raw event format for a sourcetype - Get context before writing complex queries
Execute a Splunk SPL (Search Processing Language) query to search logs and events. This tool allows you to run any valid SPL query against the Splunk instance. Examples: - "index=main error | head 10" - Find recent errors - "index=web_logs status=500 | stats count by host" - Count 500 errors by host - "source=/var/log/app.log exception | fields _time, message" - Find exceptions with specific fields The query will automatically add "search" prefix if not present. Time ranges default to last 1 hour but can be customized.
Output schemas NOT documented for any of the four tools. Tool definitions show input parameters but no return type specification, field names, or structure. LLMs cannot plan multi-step workflows or extract specific fields without knowing what data flows back.
No pagination guidance or result-limiting strategy visible. Tools like splunk_search and splunk_list_sourcetypes could return unbounded result sets. splunk_sample_events caps at 20, but others may not. Large results will blow context window and degrade LLM reasoning.
Parameter descriptions lack actionable constraints. 'filter' parameter in splunk_list_indexes is described as 'regex filter' but provides no syntax guidance (does it support alternation |, quantifiers ?, *, character classes []?). 'query' in splunk_search is described as 'SPL query' but lacks SPL syntax primer or link to docs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No tool annotations (readOnlyHint, idempotentHint, destructiveHint). All four tools are read-only but lack explicit annotation. This forces LLMs to infer from the description that calls are safe to retry without side effects.
Error handling is minimal. src/server.ts catches errors and wraps them as McpError with ErrorCode.InternalError, but provides no guidance to LLM on recovery (e.g., 'Connection timeout; try again in 5 seconds' vs 'Invalid query syntax; check your SPL'). No distinction between retryable and user-fixable errors.