Loading ToolBench
Predictive Incident Prevention Agent — AI-powered observability and security threat detection system for Splunk Enterprise using MCP Server integration
WHISPER is a Splunk MCP client with 14 tools covering query execution, metadata retrieval, and AI-assisted SPL generation. All tools have descriptions (10-100 chars, mostly adequate) and input schemas with type definitions. However, schemas lack depth: no enums for constrained inputs (e.g., meta_type, object_type), no output schemas documented, no pagination support despite tools returning lists, and no error handling guidance. Tool names follow verb_noun convention (good), but descriptions are terse and lack context on when to use each tool vs. alternatives. No tool annotations (readOnlyHint, destructiveHint). The client code shows basic JSON-RPC 2.0 wrapping but no validation, rate limiting, or recovery guidance. Baseline: 549 production tools average 194-char descriptions; WHISPER averages ~60 chars. This is a functional but minimal implementation.
Ask anything about Splunk concepts
Explain what an SPL query does in plain English
Convert natural language to SPL query
Improve SPL performance and efficiency
Detailed info on a specific index
List all available Splunk indexes
Splunk instance version, hardware, status
No output schemas documented. Tools return lists or dicts but LLMs cannot infer field names, types, or structure. Downstream tool chaining is blind.
Constrained parameters lack enums. 'meta_type' accepts 'sourcetypes, hosts, sources, etc.' as free text; 'object_type' lists 13 types but no enum constraint. LLMs will hallucinate invalid values.
No pagination support. Tools returning lists (indexes, users, knowledge objects) have no limit, offset, or cursor parameters. Large result sets will exhaust context windows.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Retrieve knowledge objects. Types: saved_searches, alerts, field_extractions, lookups, macros, tags, data_models, mltk_models, mltk_algorithms, workflow_actions, views, panels, apps
KV Store size and stats
Metadata about hosts/sources/sourcetypes
Current authenticated user details
All Splunk users with roles
Execute SPL and return results list
Run an existing saved search (beta)
Descriptions are terse (avg 60 chars vs. baseline 194). No guidance on when to use each tool, dependencies, or prerequisites. E.g., 'Splunk instance version, hardware, status' lacks context on why an agent would call this.
No error handling guidance. Client code catches exceptions and returns {'ok': False, 'error': '...'} but does not categorize errors as retryable, user-fixable, or fatal. LLMs cannot decide next steps.