Skip to main content
Glama
deslicer

MCP Server for Splunk

by deslicer

Get Splunk Health

get_splunk_health

Check Splunk server connectivity and retrieve server health, version, and system info. Test custom connection parameters to validate configurations and troubleshoot connectivity issues.

Instructions

Check Splunk server connectivity and return comprehensive health status information including server version, connection status, and system information. Supports both server-configured connections and custom connection parameters for testing different Splunk instances. Essential for connectivity troubleshooting and server validation.\n\nArgs:\n splunk_host (str, optional): Splunk server hostname or IP address (e.g., 'localhost', 'splunk.example.com', '10.1.1.100')\n splunk_port (int, optional): Splunk management port, typically 8089 (e.g., 8089, 8000, 9997)\n splunk_username (str, optional): Splunk username for authentication (e.g., 'admin', 'splunk', 'analyst')\n splunk_password (str, optional): Splunk password for authentication\n splunk_scheme (str, optional): Connection scheme - 'http' or 'https'\n splunk_verify_ssl (bool, optional): Whether to verify SSL certificates\n\nNote: If connection parameters are not provided, uses the server's configured connection.\n\nResponse Format:\nReturns dictionary with 'status', 'version', 'server_name', and 'connection_source' fields. Status can be 'connected' or 'error'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
splunk_hostNo
splunk_portNo
splunk_schemeNo
splunk_passwordNo
splunk_usernameNo
splunk_verify_sslNo
Install Server

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses the key behavior: if connection parameters are not provided, the server's configured connection is used; it also outlines possible status values ('connected' or 'error') and response fields. This conveys auth and connection aspects beyond the schema, though it could detail more edge cases or error behavior.

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 logically structured with a one-sentence summary, a categorized Args section, and a concise Response Format section. It includes exactly the details needed without unnecessary filler, and the important usage statement is front-loaded.

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 moderate complexity of six optional parameters and zero annotation or output schema, the description is complete. It explains the tool's fallback behavior, connection customization approach, and example response fields with status/version/server_name/connection_source, giving an agent everything needed to call it correctly and interpret its result.

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 description coverage is 0%, so the description fully compensates. It explicitly documents all six parameters with types, optionality, and realistic examples (e.g., hostname 'localhost', port '8089', usernames like 'admin'). This goes beyond the bare schema and gives an agent actionable onboarding for each parameter.

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 uses a specific action ('Check Splunk server connectivity') and clearly identifies the resource and scope (Splunk health status, version, connection info). It distinguishes itself from the sibling tools by focusing on a health/connectivity operation rather than searches, saved searches, app management, or dashboards. The mention of 'connectivity troubleshooting and server validation' reinforces its distinct purpose.

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 provides clear usage context, stating it is 'Essential for connectivity troubleshooting and server validation' and explaining when custom connection parameters are useful ('testing different Splunk instances'). It does not explicitly enumerate when not to use it or name alternative tools, but the context is sufficiently clear.

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

Other Tools

Latest Blog Posts

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/deslicer/mcp-for-splunk'

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