基于 FastMCP 的工具，用于通过自然语言与 Splunk Enterprise/Cloud 交互。该工具提供了一系列功能，用于通过直观的界面搜索 Splunk 数据、管理 KV 存储以及访问 Splunk 资源。
该工具有三种运行模式：
SSE 模式（默认）
基于服务器发送事件的通信
实时双向互动
适用于基于 Web 的 MCP 客户端
未提供参数时的默认模式
通过/sse端点访问
API模式
RESTful API 端点
通过/api/v1端点前缀访问
从python splunk_mcp.py api开始
STDIO模式
基于标准输入/输出的通信
与 Claude Desktop 和其他 MCP 客户端兼容
非常适合与人工智能助手直接集成
从python splunk_mcp.py stdio开始
Related MCP server: MCP Server for Splunk
Splunk 搜索：使用自然语言查询执行 Splunk 搜索
索引管理：列出并检查 Splunk 索引
用户管理：查看和管理 Splunk 用户
KV 商店操作：创建、列出和管理 KV 商店集合
异步支持：采用异步/等待模式构建，以获得更好的性能
详细日志：使用表情符号指示器进行全面日志记录，以获得更好的可视性
SSL 配置：灵活的 SSL 验证选项，满足不同的安全要求
增强的调试：详细的连接和错误日志，用于故障排除
全面测试：单元测试涵盖所有主要功能
错误处理：使用适当的状态代码进行强大的错误处理
SSE 合规性：完全符合 MCP SSE 规范
可通过 MCP 界面使用以下工具：
列表工具
列出所有可用的 MCP 工具及其描述和参数
健康检查
返回可用 Splunk 应用程序列表以验证连接性
ping
简单 ping 端点来验证 MCP 服务器是否处于活动状态
当前用户
返回有关当前已验证用户的信息
列出用户
返回所有用户及其角色的列表
列表索引
返回所有可访问的 Splunk 索引的列表
获取索引信息
返回有关特定索引的详细信息
参数：index_name（字符串）
索引和源类型
返回索引及其源类型的完整列表
搜索_splunk
执行 Splunk 搜索查询
参数：
search_query（字符串）：Splunk 搜索字符串
最早的时间（字符串，可选）：搜索窗口的开始时间
latest_time（字符串，可选）：搜索窗口的结束时间
max_results（整数，可选）：返回的最大结果数
列出已保存的搜索
返回 Splunk 实例中已保存的搜索列表
列表_kvstore_collections
列出所有 KV 商店集合
创建_kvstore_collection
创建一个新的 KV 存储集合
参数：collection_name（字符串）
删除_kvstore_collection
删除现有的 KV 存储集合
参数：collection_name（字符串）
在 SSE 模式下运行时，以下端点可用：
/sse ：以文本/事件流格式返回 SSE 连接信息
提供有关 SSE 连接的元数据
包含消息端点的 URL
提供协议和功能信息
/sse/messages ：主 SSE 流端点
流式传输心跳等系统事件
保持持久连接
发送格式正确的 SSE 事件
/sse/health ：SSE 模式的健康检查端点
以 SSE 格式返回状态和版本信息
MCP 实现包括一致的错误处理：
无效的搜索命令或格式错误的请求
权限不足
未找到资源
输入验证无效
意外的服务器错误
Splunk 服务器连接问题
所有错误响应都包含一条解释错误的详细消息。
Python 3.10 或更高版本
依赖管理的诗歌
Splunk Enterprise/云实例
具有必要权限的适当 Splunk 凭证
克隆存储库：
git clone <repository-url>
cd splunk-mcp使用 Poetry 安装依赖项：
poetry install复制示例环境文件并配置您的设置：
cp .env.example .env使用您的 Splunk 凭证更新.env文件：
SPLUNK_HOST=your_splunk_host
SPLUNK_PORT=8089
SPLUNK_USERNAME=your_username
SPLUNK_PASSWORD=your_password
SPLUNK_SCHEME=https
VERIFY_SSL=true
FASTMCP_LOG_LEVEL=INFO拉取最新镜像：
docker pull livehybrid/splunk-mcp:latest按照上述方法创建.env文件或直接使用环境变量。
使用 Docker Compose 运行：
docker-compose up -d或者直接使用 Docker：
docker run -i \
--env-file .env \
livehybrid/splunk-mcp该工具可以以三种模式运行：
SSE 模式（MCP 客户端的默认模式）：
# Start in SSE mode (default)
poetry run python splunk_mcp.py
# or explicitly:
poetry run python splunk_mcp.py sse
# Use uvicorn directly:
SERVER_MODE=api poetry run uvicorn splunk_mcp:app --host 0.0.0.0 --port 8000 --reloadSTDIO模式：
poetry run python splunk_mcp.py stdio该项目同时支持新版docker compose (V2) 和旧版docker-compose (V1) 命令。以下示例使用的是 V2 语法，但两种语法均受支持。
SSE 模式（默认）：
docker compose up -d mcpAPI模式：
docker compose run --rm mcp python splunk_mcp.py apiSTDIO模式：
docker compose run -i --rm mcp python splunk_mcp.py stdio该项目包含 Docker 中的专用测试环境：
运行所有测试：
./run_tests.sh --docker运行特定的测试组件：
# Run only the MCP server
docker compose up -d mcp
# Run only the test container
docker compose up test
# Run both with test results
docker compose up --abort-on-container-exit测试结果将在./test-results目录中提供。
建筑图像：
# Build both images
docker compose build
# Build specific service
docker compose build mcp
docker compose build test查看日志：
# View all logs
docker compose logs
# Follow specific service logs
docker compose logs -f mcp调试：
# Run with debug mode
DEBUG=true docker compose up mcp
# Access container shell
docker compose exec mcp /bin/bash注意：如果您使用的是 Docker Compose V1，请将上述命令中的docker compose替换为docker-compose 。
环境变量：
永远不要提交.env文件
使用.env.example作为模板
考虑在生产中使用 Docker secrets
SSL验证：
建议在生产环境中使用VERIFY_SSL=true
可以禁用以进行开发/测试
通过环境变量配置
端口暴露：
只暴露必要的端口
尽可能使用内部 Docker 网络
在生产中考虑网络安全
配置以下环境变量：
SPLUNK_HOST ：您的 Splunk 主机地址
SPLUNK_PORT ：Splunk 管理端口（默认值：8089）
SPLUNK_USERNAME ：您的 Splunk 用户名
SPLUNK_PASSWORD ：您的 Splunk 密码
SPLUNK_SCHEME ：连接方案（默认值：https）
VERIFY_SSL ：启用/禁用 SSL 验证（默认值：true）
FASTMCP_LOG_LEVEL ：日志记录级别（默认值：INFO）
SERVER_MODE ：使用 uvicorn 时的服务器模式（sse、api、stdio）
该工具提供了灵活的 SSL 验证选项：
默认（安全）模式：
VERIFY_SSL=true完整的 SSL 证书验证
已启用主机名验证
推荐用于生产环境
轻松模式：
VERIFY_SSL=falseSSL 证书验证已禁用
已禁用主机名验证
适用于测试或自签名证书
该项目包括使用 pytest 进行全面测试覆盖以及使用自定义 MCP 客户端进行端到端测试：
基本测试执行：
poetry run pytest覆盖范围报告：
poetry run pytest --cov=splunk_mcp详细输出：
poetry run pytest -v该项目包括一个自定义的 MCP 客户端测试脚本，该脚本连接到实时 SSE 端点并测试所有工具：
# Test all tools
python test_endpoints.py
# Test specific tools
python test_endpoints.py health_check list_indexes
# List all available tools
python test_endpoints.py --list该脚本通过以下方式充当 MCP 客户端：
连接到/sse端点以获取消息 URL
将工具调用发送到消息端点
处理 SSE 事件以提取工具结果
根据预期格式验证结果
这为 SSE 接口提供了真实世界的测试，因为它将被实际的 MCP 客户端使用。
该项目采用三种互补的测试方法：
MCP 集成测试（ tests/test_api.py ） ：
通过mcp.call_tool()测试 MCP 工具接口
使用 FastMCP 验证工具注册是否正确
确保正确的响应格式和数据结构
验证 MCP 接口级别的错误处理
**注意：**理想情况下，应将此文件重命名为test_mcp.py ，以更好地反映其用途
直接功能测试（ tests/test_endpoints_pytest.py ） ：
直接测试 Splunk 功能（绕过 MCP 层）
提供更全面的功能实现细节
测试边缘情况、参数变化和错误处理
包括 SSL 配置、连接参数和超时测试
使用参数化测试实现高效的测试覆盖
端到端 MCP 客户端测试（ test_endpoints.py ） ：
行为类似于连接到 SSE 端点的真实 MCP 客户端
测试从连接到工具调用到响应解析的完整流程
验证实际的 SSE 协议实现
使用真实参数针对实时服务器测试工具
配置测试（ tests/test_config.py ） ：
环境变量解析测试
SSL 验证设置
连接参数验证
测试支持：
使用 pytest-asyncio 进行异步测试
使用 pytest-cov 进行覆盖率报告
使用 pytest-mock 进行模拟
参数化测试
连接超时测试
基本连接：
该工具现在执行基本的 TCP 连接测试
检查8089端口是否可以访问
验证网络路由和防火墙
SSL 问题：
如果看到 SSL 错误，请尝试设置VERIFY_SSL=false
检查证书有效性和信任链
验证主机名是否与证书匹配
身份验证问题：
验证 Splunk 凭证
检查用户权限
确保帐户未被锁定
调试：
设置FASTMCP_LOG_LEVEL=DEBUG获取详细日志
检查连接日志中的具体错误消息
查看 SSL 配置消息
SSE 连接问题：
验证是否可以通过/sse访问 SSE 端点
检查正确的内容类型标头
使用浏览器开发者工具检查 SSE 连接
您可以通过将 Splunk MCP 配置为使用 SSE 或 STDIO 模式来将其与 Claude Desktop 集成。将以下配置添加到claude_desktop_config.json文件中：
{
"mcpServers": {
"splunk": {
"command": "poetry",
"env": {
"SPLUNK_HOST": "your_splunk_host",
"SPLUNK_PORT": "8089",
"SPLUNK_USERNAME": "your_username",
"SPLUNK_PASSWORD": "your_password",
"SPLUNK_SCHEME": "https",
"VERIFY_SSL": "false"
},
"args": [
"--directory",
"/path/to/splunk-mcp",
"run",
"python",
"splunk_mcp.py",
"stdio"
]
}
}
}{
"mcpServers": {
"splunk": {
"command": "poetry",
"env": {
"SPLUNK_HOST": "your_splunk_host",
"SPLUNK_PORT": "8089",
"SPLUNK_USERNAME": "your_username",
"SPLUNK_PASSWORD": "your_password",
"SPLUNK_SCHEME": "https",
"VERIFY_SSL": "false",
"FASTMCP_PORT": "8001",
"DEBUG": "true"
},
"args": [
"--directory",
"/path/to/splunk-mcp",
"run",
"python",
"splunk_mcp.py",
"sse"
]
}
}
}配置完成后，您可以通过 Claude 使用自然语言与 Splunk 进行交互。示例：
列出可用索引：
What Splunk indexes are available?搜索 Splunk 数据：
Search Splunk for failed login attempts in the last 24 hours获取系统健康：
Check the health of the Splunk system管理 KV 存储：
List all KV store collectionsMCP 工具将自动供 Claude 使用，允许它通过自然语言命令执行这些操作。
[此处为您的许可证]
FastMCP 框架
适用于 Python 的 Splunk SDK
Python-decouple 用于配置管理
SSE Starlette 用于 SSE 实施
Get information about the currently authenticated user.
This endpoint retrieves:
- Basic user information (username, real name, email)
- Assigned roles
- Default app settings
- User type
Returns:
Dict[str, Any]: Dictionary containing user information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly describes what information is retrieved (e.g., basic info, roles, settings) and the return type, but lacks details on authentication requirements, error handling, or rate limits. This is adequate but has gaps for a tool with no annotations.
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 well-structured and front-loaded, starting with the core purpose followed by bullet points for retrieved information and return details. Every sentence adds value without redundancy, making it efficient and easy to parse.
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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is largely complete, covering purpose, retrieved data, and return type. However, it could benefit from more behavioral context, such as authentication notes, to fully compensate for the lack of annotations.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's function and output, which aligns with the schema's simplicity.
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 explicitly states the verb 'Get' and resource 'information about the currently authenticated user,' making the purpose specific and clear. It distinguishes this tool from siblings like 'list_users' by focusing on the current authenticated user rather than listing all users.
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 implies usage context by specifying 'currently authenticated user,' suggesting it should be used when user-specific data is needed. However, it does not explicitly state when to use alternatives like 'list_users' or provide exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all indexes and their sourcetypes.
This endpoint performs a search to gather:
- All available indexes
- All sourcetypes within each index
- Event counts for each sourcetype
- Time range information
Returns:
Dict[str, Any]: Dictionary containing:
- indexes: List of all accessible indexes
- sourcetypes: Dictionary mapping indexes to their sourcetypes
- metadata: Additional information about the search
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does (performs a search to gather specific data types) and outlines the return structure in detail. However, it doesn't mention potential limitations like performance impact, authentication requirements, or rate limits, which would be helpful for a search operation.
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 perfectly structured: a clear purpose statement followed by bullet points detailing what the search gathers and a formatted Returns section. Every sentence adds value with zero redundancy, making it easy to scan and understand.
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 zero-parameter tool with no annotations or output schema, the description provides excellent context about the operation and return values. It explains the search behavior and output structure thoroughly. The only minor gap is lack of information about potential side effects or performance characteristics.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics instead, detailing what data is returned. This exceeds the baseline expectation for a zero-parameter tool.
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 specific action ('Get a list') and resources ('all indexes and their sourcetypes'), distinguishing it from siblings like list_indexes (which likely just lists indexes) and get_index_info (which likely provides detailed info about a specific index). The verb+resource combination is precise and unambiguous.
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 implies usage for gathering comprehensive index and sourcetype data with event counts and time ranges, but doesn't explicitly state when to use this tool versus alternatives like list_indexes or get_index_info. There's no guidance on prerequisites, exclusions, or specific scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a specific Splunk index.
Args:
index_name: Name of the index to get metadata for
Returns:
Dictionary containing index metadata
| Name | Required | Description | Default |
|---|---|---|---|
| index_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'gets metadata' which implies a read-only operation, but doesn't specify permissions required, rate limits, error conditions, or what specific metadata fields are returned. The return format is vaguely described as a 'dictionary', lacking detail on structure or content.
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 a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose: the first states the tool's function, the second explains the parameter, and the third describes the return. No redundant or verbose language is present.
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 single-parameter read operation with no annotations and no output schema, the description provides basic purpose and parameter explanation but lacks sufficient behavioral context. It doesn't detail what metadata is included, error handling, or authentication requirements, leaving gaps for an agent to use the tool effectively without additional context.
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?
Schema description coverage is 0%, but the description compensates by explaining the single parameter 'index_name' as 'Name of the index to get metadata for', adding semantic meaning beyond the schema's title 'Index Name'. However, it doesn't provide format examples, constraints, or validation rules for the index name parameter.
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 verb 'Get' and resource 'metadata for a specific Splunk index', making the purpose unambiguous. It distinguishes from siblings like 'list_indexes' (which lists multiple indexes) by focusing on metadata retrieval for a single specified index. However, it doesn't explicitly contrast with 'get_indexes_and_sourcetypes' which might overlap in functionality.
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 implies usage when you need metadata for a specific index (vs. listing indexes), but doesn't provide explicit guidance on when to choose this tool over alternatives like 'get_indexes_and_sourcetypes' or 'list_indexes'. No prerequisites, exclusions, or comparative context are mentioned, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get basic Splunk connection information and list available apps (same as health_check but for endpoint consistency)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states what the tool does (get connection info and list apps) but lacks details on permissions required, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 perfectly concise and front-loaded: the first clause states the core purpose, and the second provides important sibling context. Every sentence earns its place with zero wasted words or redundancy.
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?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is reasonably complete for a basic health/status tool. However, without annotations or output schema, it should ideally mention what specific information is returned or any authentication requirements. The sibling comparison adds useful context.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, which is correct. Baseline for 0 parameters is 4.
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: 'Get basic Splunk connection information and list available apps'. It specifies both the verb ('Get') and the resources ('connection information', 'available apps'), making the function unambiguous. However, it doesn't explicitly differentiate from its sibling 'health_check' beyond noting they're functionally equivalent for endpoint consistency.
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 clear context by stating this tool is 'same as health_check but for endpoint consistency', which implicitly guides usage toward this tool when endpoint consistency is needed. It doesn't explicitly state when NOT to use it or name alternatives beyond the mentioned sibling, but the comparison offers practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get basic Splunk connection information and list available apps
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states what the tool does, it doesn't describe important behavioral aspects like authentication requirements, rate limits, error conditions, or what specific information constitutes 'basic Splunk connection information.' The description is functional but lacks operational context.
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 a single, efficient sentence that communicates the complete purpose without any wasted words. It's appropriately sized for a zero-parameter diagnostic tool and front-loads the essential information. Every word earns its place in the description.
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?
Given zero parameters and no output schema, the description adequately covers what the tool does but leaves important questions unanswered about return format, error handling, and authentication requirements. For a diagnostic tool that likely returns structured data about system health, more detail about what constitutes 'basic connection information' would be helpful.
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?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, which is correct for this case. A baseline of 4 is appropriate when no parameters need documentation.
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 with specific verbs ('Get', 'list') and resources ('basic Splunk connection information', 'available apps'), making it immediately understandable. It distinguishes this tool from siblings like 'ping' (simple connectivity) or 'list_users' (specific resource listing) by combining connection verification with app inventory.
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 implies usage for checking Splunk connectivity and discovering apps, but doesn't explicitly state when to use this versus alternatives like 'ping' (simpler connectivity check) or 'list_saved_searches' (specific resource listing). No guidance is provided about when NOT to use this tool or what prerequisites might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all available Splunk indexes.
Returns:
Dictionary containing list of indexes
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns a dictionary with a list of indexes, which is basic behavioral information. However, it lacks details on permissions, rate limits, or whether the list is paginated or filtered, which are important for a read operation in a system like Splunk.
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 concise with two sentences that directly state the purpose and return value. It's front-loaded with the main action, though it could be slightly more structured by explicitly separating usage notes from return details.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and return format, but for a tool in a complex system like Splunk, it could benefit from more context on limitations or typical use cases.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add parameter details, but this is acceptable given the lack of parameters, aligning with the baseline for 0 parameters.
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 with 'Get a list of all available Splunk indexes,' which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_indexes_and_sourcetypes' or 'get_index_info,' which might offer overlapping or related functionality.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this tool is preferred, such as for a simple list versus more detailed index information available in other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all KV store collections across apps.
Returns:
List of KV store collections with metadata including app, fields, and accelerated fields
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool lists collections and describes the return format, which is helpful. However, it lacks details on potential side effects, authentication needs, rate limits, or error handling, leaving gaps in behavioral context for a tool that might involve data access across apps.
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 extremely concise with only two sentences, front-loading the purpose and then detailing the return format. Every sentence earns its place by providing essential information without any wasted words or redundancy.
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?
Given the tool's complexity (listing collections across apps) and the absence of annotations and output schema, the description is minimally adequate. It covers the purpose and return format, but for a tool that might involve cross-app data access, more context on permissions, scope, or limitations would enhance completeness.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the return values instead, adding value by specifying what metadata is included in the output, which compensates for the lack of an output schema.
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 action ('List all KV store collections') and the resource ('across apps'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_indexes' or 'list_saved_searches', which would require mentioning what makes KV store collections distinct from those other resources.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare it to sibling tools like 'get_indexes_and_sourcetypes' or 'list_indexes', leaving the agent without explicit direction on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved searches in Splunk
Returns:
List of saved searches with their names, descriptions, and search queries
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the return format ('List of saved searches with their names, descriptions, and search queries'), which is helpful, but lacks details on permissions, rate limits, pagination, or error handling for a read operation in Splunk.
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 front-loaded with the core purpose in the first sentence and adds return details in a second sentence. It's efficient with zero waste, though slightly brief for a tool with no annotations, which keeps it from a perfect score.
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?
Given 0 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It explains what the tool does and the return format, but for a read operation in Splunk with no annotations, it could benefit from more behavioral context like access requirements or data scope.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately omits parameter details, earning a high baseline score for not adding unnecessary information.
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 verb ('List') and resource ('all saved searches in Splunk'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_indexes' or 'list_users' beyond specifying the resource type, which prevents a perfect score.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or comparisons to sibling tools like 'search_splunk' or 'get_indexes_and_sourcetypes', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available MCP tools.
Returns:
List of all available tools with their name, description, and parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return format ('List of all available tools with their name, description, and parameters'), which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or pagination behavior. The description provides some output information but misses key operational details.
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 extremely concise and well-structured. Two sentences efficiently convey the tool's purpose and return format with zero wasted words. It's front-loaded with the core functionality and follows with return details.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and what it returns, but doesn't provide context about when to use it or behavioral constraints. For a tool with no structured metadata, the description should do more to compensate, particularly around usage guidelines and operational behavior.
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?
The tool has 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters since none exist. It appropriately focuses on the tool's function and return value rather than parameter details. The baseline for 0 parameters is 4.
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: 'List all available MCP tools' with a specific verb ('List') and resource ('MCP tools'). It distinguishes from siblings by focusing on tools rather than users, indexes, searches, etc. However, it doesn't explicitly differentiate from similar listing tools like list_indexes or list_users beyond the resource type.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, timing considerations, or compare it to other listing tools. It simply states what it does without context about when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Splunk users (requires admin privileges)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the admin privilege requirement, which is useful behavioral context. However, it doesn't mention other traits like pagination, rate limits, or return format, leaving gaps in behavioral understanding.
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 a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes essential context (admin privileges) without unnecessary elaboration.
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 0 parameters and no output schema, the description covers the basic purpose and permission requirement adequately. However, without annotations or output schema, it lacks details on return format (e.g., list structure, fields) and other behavioral aspects, making it minimally complete.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline 4 for this context.
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 verb ('List') and resource ('all Splunk users'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'current_user' or 'list_indexes', which would require a 5.
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 clear context with 'requires admin privileges', indicating when this tool is appropriate. It doesn't explicitly state when not to use it or name alternatives like 'current_user' for non-admin scenarios, preventing a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simple ping endpoint to check server availability and get basic server information.
This endpoint provides a lightweight way to:
- Verify the server is running and responsive
- Get basic server information including version and server time
- Check connectivity without making complex API calls
Returns:
Dict[str, Any]: Dictionary containing status and basic server information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing behavioral traits: it's a read-only operation that returns server information, doesn't modify anything, and provides version and server time. It could mention response format details or error behavior, but covers the essential safety profile adequately.
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 perfectly structured: opening statement of purpose, bulleted list of specific capabilities, and clear return value description. Every sentence earns its place with zero wasted words, and information is front-loaded effectively.
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 zero-parameter diagnostic tool with no annotations and no output schema, the description provides complete context: purpose, when to use, what it returns, and how it differs from other tools. The return format description ('Dict[str, Any]') compensates for the missing output schema.
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?
The tool has 0 parameters with 100% schema coverage, so the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and behavior.
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 with specific verbs ('check server availability', 'get basic server information') and distinguishes it from siblings by emphasizing it's a 'lightweight way' for connectivity verification rather than complex API operations like search_splunk or list_users.
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 explicitly states when to use this tool: 'to check server availability', 'verify the server is running and responsive', and 'check connectivity without making complex API calls'. It clearly distinguishes this from more complex operations available in sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a Splunk search query and return the results.
Args:
search_query: The search query to execute
earliest_time: Start time for the search (default: 24 hours ago)
latest_time: End time for the search (default: now)
max_results: Maximum number of results to return (default: 100)
Returns:
List of search results
| Name | Required | Description | Default |
|---|---|---|---|
| search_query | Yes | ||
| earliest_time | No | -24h | |
| latest_time | No | now | |
| max_results | No |
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 states the tool executes a search and returns results, but lacks details on permissions required, rate limits, whether it's read-only or has side effects, response format, or error handling. For a tool with 4 parameters and no annotation coverage, this is a significant gap in transparency.
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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by a bulleted list of args with explanations and defaults, and ends with return information. Every sentence earns its place by adding value, with no redundant or verbose content, making it easy to parse and understand.
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?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is partially complete. It covers parameter semantics well but lacks behavioral context like permissions or rate limits, and without an output schema, it doesn't detail the structure of the 'List of search results'. This leaves gaps for an AI agent to fully understand tool behavior and outputs.
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?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'search_query' as the query to execute, 'earliest_time' and 'latest_time' as time bounds with defaults, and 'max_results' as a limit. This compensates fully for the schema's lack of descriptions, providing clear semantics for all parameters.
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: 'Execute a Splunk search query and return the results.' This specifies the verb ('execute') and resource ('Splunk search query'), making it understandable. However, it doesn't explicitly differentiate this tool from potential siblings like 'list_saved_searches' or 'get_indexes_and_sourcetypes', which might also involve search-related operations, so it falls short of a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_saved_searches' for retrieving pre-defined searches or 'get_indexes_and_sourcetypes' for exploring data sources, nor does it specify prerequisites or contexts for executing searches. This lack of comparative information limits its utility for an AI agent in selecting the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
current_userget_index_infoget_indexes_and_sourcetypeshealthhealth_checklist_indexeslist_kvstore_collectionslist_saved_searcheslist_toolslist_userspingsearch_splunkScored across 12 tools
There is significant overlap between several tools, which could cause confusion. For example, 'health' and 'health_check' appear to be duplicates, and 'list_indexes', 'get_indexes_and_sourcetypes', and 'get_index_info' all relate to indexes with unclear boundaries. However, descriptions help differentiate some tools, such as 'search_splunk' being distinct for query execution.
Naming is inconsistent with mixed conventions. Some tools use verb_noun patterns like 'list_indexes' and 'search_splunk', while others use noun-only forms like 'health' and 'ping'. There are also deviations like 'get_indexes_and_sourcetypes' using 'and' in the name, and 'list_tools' is an outlier as it's meta to the server itself.
With 12 tools, the count is reasonable for a Splunk MCP server, covering user management, indexing, searches, and health checks. It's slightly heavy due to redundant tools like 'health' and 'health_check', but overall well-scoped for the domain without being overwhelming.
The toolset covers core Splunk operations like searching, indexing, and user management, but has notable gaps. For example, there are tools to list saved searches but no way to create, update, or delete them, and similar gaps exist for KV store collections and indexes. This could lead to dead ends for agents trying to perform full lifecycle management.
Official Microsoft MCP Server to query Microsoft Entra data using natural language
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
