Skip to main content
Glama
deslicer

MCP Server for Splunk

by deslicer

Run Oneshot Search

run_oneshot_search

Run a Splunk search to completion and return the first page of results. If more results exist, retrieve them by job ID and offset.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoPage size 1-100 (default 50; 0 uses default)
queryYesSPL to execute
offsetNoResult offset (default 0)
latest_timeNoEnd time (default 'now')now
max_resultsNoDeprecated alias for count
earliest_timeNoStart time (default '-15m')-15m

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.12
    • changedInput schema / properties / count / description
      Previous value: -"Page size 1-100 (default 50)"New value: +"Page size 1-100 (default 50; 0 uses default)"
  2. Changed9 schema fields changedv0.6.11
    • addedInput schema / properties / count
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Page size 1-100 (default 50)"
      +}
    • addedInput schema / properties / earliest_time / description
      Added value: +"Start time (default '-15m')"
    • addedInput schema / properties / latest_time / description
      Added value: +"End time (default 'now')"
    • addedInput schema / properties / max_results / anyOf
      Added value: +[
      +  {
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / max_results / default
      Previous value: -100New value: +null
    • addedInput schema / properties / max_results / description
      Added value: +"Deprecated alias for count"
    • removedInput schema / properties / max_results / type
      Removed value: -"integer"
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Result offset (default 0)",
      +  "type": "integer"
      +}
    • addedInput schema / properties / query / description
      Added value: +"SPL to execute"
  3. Changed1 schema field changedv0.5.1
    • addedInput schema / additionalProperties
      Added value: +false
  4. First observedv0.5.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that the search waits for completion, returns only one page, and persists a job for later pages. It could additionally mention timeout behavior or whether a search job expires, but the core execution model is clearly conveyed.

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

Conciseness5/5

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

Three sentences with no filler: the first states the core action, the second gives the alternative for long-running queries, and the third gives the exact pagination rule. Information is front-loaded and every sentence earns its place.

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

Completeness5/5

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

Given there is no output schema, the description compensates by naming the key output fields (has_more, next_offset, job_id) and the follow-up call. The sibling run_splunk_search is also referenced for the long-running case, making the tool's role in the larger workflow complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds useful context about pagination via has_more and next_offset, but it does not elaborate on parameter semantics beyond what the schema provides.

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

Purpose5/5

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

The description states a clear verb and resource: 'Run a Splunk search, wait for completion, and return one page of results.' It also distinguishes itself from both run_splunk_search and get_search_job_results, so an agent can tell exactly what this tool is for.

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

Usage Guidelines5/5

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

Explicitly directs long-running queries to run_splunk_search and provides a precise follow-up instruction when has_more is true: 'call get_search_job_results with job_id and offset=next_offset.' This leaves no ambiguity about when to use this tool and what to do next.

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