MCP Server for Splunk

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the immediate execution with no job creation, the performance constraints (~30s runtime), security constraints (results constrained by user permissions), and output format (returns events/rows with timing and executed query). It doesn't mention rate limits or error handling, but covers the essential operational characteristics well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with zero wasted sentences. It front-loads the core purpose, follows with usage guidelines, then provides detailed parameter documentation. Each section serves a clear purpose: the first paragraph explains what the tool does and when to use it, the second covers outputs and security, and the third documents all parameters thoroughly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, no output schema, and 4 parameters, the description provides substantial context. It covers purpose, usage guidelines, behavioral traits, security constraints, and detailed parameter documentation. The main gap is the lack of output schema documentation, but the description does mention what the tool returns ('events or rows with timing and the executed query'). Given the complexity, it's quite complete but not exhaustive about return format details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well by providing detailed parameter semantics. It explains each parameter's purpose, format, examples, defaults, and constraints (e.g., 'max_results' range 1-10000). The description adds significant value beyond the bare schema, though it could provide more guidance on query construction or time format specifics for complete coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Run a Splunk search and return results immediately (no job created).' It specifies the verb ('run'), resource ('Splunk search'), and distinguishes it from sibling tools by contrasting with 'run_splunk_search' for long-running searches. The description goes beyond just restating the name by explaining the immediate execution characteristic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('quick lookup or small result set (typically under ~30s) such as simple stats, ad‑hoc checks, or previews') and when not to use it ('Do not use for long‑running or heavy searches—prefer run_splunk_search in those cases'). It names the specific alternative tool and provides clear context for appropriate usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.