Splunk Intelligence MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Tools are mostly distinct: investigate_start initiates, get_findings retrieves current findings, hint injects hints, lsp_call_chain traces code, pause halts, query_examples provides example queries, submit_report submits a report. There is slight overlap between get_findings and the findings returned by investigate_start, but descriptions clarify the different usage points.
Naming Consistency3/5
All tools share the 'splunk__' prefix and use lowercase with underscores, but the verb-noun pattern is inconsistent: 'get_findings' (verb_noun), 'hint' (just verb), 'investigate_start' (verb_noun), 'lsp_call_chain' (noun_verb), 'pause' (verb), 'query_examples' (noun_verb), 'submit_report' (verb_noun). Some tools are single words, others have multiple parts, but overall readable.
Tool Count4/5
Seven tools is a reasonable count for a focused investigation server. It covers the core workflow without being excessive. A few more could be added (e.g., listing past investigations), but the current count is appropriate.
Completeness4/5
The tool set covers the main investigation lifecycle: start, get findings, inject hints, trace code, pause, get examples, and submit report. Missing operations like direct arbitrary SPL querying are partially handled through investigate_start and submit_report queries. Overall, it's well-scoped with minor gaps.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 56 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action but does not reveal consequences such as whether the investigation can be resumed, if state is saved, or what happens during the pause. This is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no waste. It is appropriately sized for a simple action, though it could benefit from additional context without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has one parameter and an output schema, the description is incomplete. It does not explain what the output contains, what 'current iteration' means in this context, or any necessary preconditions (e.g., investigation must be running). More completeness is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema does not describe the param. The tool description also fails to describe the 'run_id' parameter or its role. The description adds no semantic value beyond the schema for the parameter, and it does not compensate for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('pause') and the resource ('the investigation after the current iteration completes'). It uses a specific verb and resource, and it largely distinguishes from sibling tools which perform different functions (e.g., get_findings, hint). However, it could be slightly more precise about what 'iteration' refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or any context for invocation. This is a gap for a tool that presumably controls execution flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only status, auth requirements, or side effects. It only implies a read operation ('Get', 'inspect') without explicit assurance of non-destructiveness.
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?
The description is extremely concise (two sentences) with no redundant information. The primary purpose is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has an output schema (not shown) and sibling tools like 'splunk__investigate_start' provide context, the description lacks guidance on 'run_id' and the 'active investigation session' concept, requiring the agent to infer from tool names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the 'run_id' parameter—its purpose, format, or how to obtain it. This is a critical gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get[s] current findings from the active investigation session,' specifying the verb 'Get' and resource 'findings.' It distinguishes from siblings like 'splunk__submit_report' by context (active session, mid-loop), though it could be more explicit about what 'current' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool 'to inspect the latest detector output mid-loop,' providing clear context for invocation. However, it does not mention when not to use it or describe alternatives, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior: the hint is included in findings passed to the next reasoning step. However, it omits details like whether multiple hints can be combined, persistence, or mutability, leaving some ambiguity.
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?
Two clear sentences plus a relevant example, front-loaded with the action. No wasted words; efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter design and presence of an output schema, the description covers the main behavior. Minor gaps like whether hints stack or are one-shot, but overall sufficient for a straightforward injection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'hint' with an example but does not define 'run_id', leaving that parameter's purpose unclear. Partial improvement but incomplete.
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 clearly states the tool injects an analyst hint into the investigation for the next iteration, with a concrete example. This distinguishes it from siblings which handle findings, pausing, reports, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to inject a hint vs. submit a report or start a new investigation). The description only explains what it does, not the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool loads events, runs detectors, and returns findings. It also mentions the cross-referencing behavior when repo_path is provided. Since no annotations are supplied, the description sufficiently covers the tool's behavior, though it could mention if the operation is read-only or has side effects.
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?
The description is concise and well-structured, with a clear overview sentence followed by a focused list of parameter details. Every sentence adds necessary information without redundancy.
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?
The description covers all parameters and their interplay, notes prerequisites (SPLUNK_URL for live queries), and states the return format. Given the presence of an output schema, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, the source vs spl trade-off, default time ranges, and the repo_path's role in code cross-referencing. This adds significant value beyond the schema's minimal information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a Splunk investigation, loads events, runs detectors, and returns structured findings. It effectively communicates the primary verb and resource, though it could be improved by explicitly differentiating from siblings like splunk__get_findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use source vs spl parameters and explains the prerequisites for live queries. However, it lacks explicit direction on when to use this tool versus alternative sibling tools, such as when to use splunk__get_findings instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It transparently describes the output structure (JSON list with fields like area, spl, result_rows, etc.) and behavior (sorted by most recent first). No contradictions observed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, though the Args block adds some verbosity. Overall, every sentence adds value, and it is appropriately sized for the tool.
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 the tool has an output schema, the description need not explain return values in detail, but it does so anyway. It covers all necessary aspects: what the tool does, when to use it, parameter details, and output format. Complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It does so by explaining both parameters: area with filtering guidance and example labels, and limit with default value. This adds meaningful context beyond the raw schema.
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 clearly states it returns example SPL queries from past investigations, using the specific verb 'Return' and resource 'example SPL queries'. It distinguishes from sibling tools by emphasizing that these examples are from past investigations in splunk.db, providing grounding for follow-up queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to ground follow-up queries in field names and patterns', providing clear usage context. However, it does not explicitly state when not to use or contrast with siblings, but the implied usage is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the tool returns a JSON call chain or an error if repo_path is missing or symbol unresolved. It doesn't mention destructive behavior (none expected) and gives direction/depth options, providing good transparency.
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?
The description is concise with no wasted words. Each sentence serves a purpose: stating the core action, providing usage context, and detailing parameters. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 2 required, and an output schema exists, the description adequately covers what the tool does and returns. It mentions error conditions. It could mention prerequisites like calling investigate_start first, but the error note indirectly addresses that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description explains all 6 parameters: run_id, symbol, file_path, line, direction, and depth. It gives examples for symbol, explains direction values, default depth, and optional file_path/line, adding significant meaning beyond the schema.
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 clearly states the tool's purpose: tracing a function or symbol through the microservice call graph using LSP, and it is used during the Reason step. It distinguishes itself from siblings like splunk__get_findings and splunk__hint by focusing on call graph tracing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool during the Reason step to find code paths producing log errors. While it does not list when not to use or provide alternatives, the context is clear and sufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the lifecycle: stores report, executes queries, builds findings, and returns status with either findings or a UI URL. It does not cover error handling, rate limits, or side effects like overwriting, but provides reasonable transparency for typical use.
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?
The description is concise, with a brief introduction followed by an Args section listing parameters and their meanings. No extraneous information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the main workflow and return types. It does not detail the output schema content but mentions status and fields, which is sufficient for an agent to understand the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains run_id as coming from splunk__investigate_start, report as markdown with confidence level, and queries as SPL strings starting with '-- area' comment. This adds significant detail beyond the bare schema.
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 clearly states the tool's purpose: submitting an investigation report and follow-up SPL queries to the server. It explains the workflow of storing, executing, and returning results, distinguishing it from sibling tools like splunk__get_findings (retrieval) or splunk__investigate_start (initiation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the run_id parameter comes from splunk__investigate_start, implying usage after that tool. It does not explicitly exclude scenarios or mention alternatives, but the context is clear. Sibling tool names provide implicit guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![splunk-intelligence MCP server](https://glama.ai/mcp/servers/debaditya-mohankudo/splunk-intelligence/badges/card.svg)](https://glama.ai/mcp/servers/debaditya-mohankudo/splunk-intelligence)

Score Badge

Copy to your README.md:

[![splunk-intelligence MCP server](https://glama.ai/mcp/servers/debaditya-mohankudo/splunk-intelligence/badges/score.svg)](https://glama.ai/mcp/servers/debaditya-mohankudo/splunk-intelligence)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/debaditya-mohankudo/splunk-intelligence'

If you have feedback or need assistance with the MCP directory API, please join our Discord server