자연어를 통해 Splunk Enterprise/Cloud와 상호 작용하는 FastMCP 기반 도구입니다. 이 도구는 직관적인 인터페이스를 통해 Splunk 데이터 검색, KV 저장소 관리, Splunk 리소스 접근 등의 기능을 제공합니다.
이 도구는 세 가지 모드로 작동합니다.
SSE 모드 (기본값)
서버에서 보낸 이벤트 기반 통신
실시간 양방향 상호작용
웹 기반 MCP 클라이언트에 적합
인수가 제공되지 않을 경우 기본 모드
/sse 엔드포인트를 통해 액세스
API 모드
RESTful API 엔드포인트
/api/v1 엔드포인트 접두사를 통해 액세스
python splunk_mcp.py api 로 시작하세요
STDIO 모드
표준 입출력 기반 통신
Claude Desktop 및 기타 MCP 클라이언트와 호환 가능
AI 어시스턴트와의 직접 통합에 이상적
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 앱 목록을 반환합니다.
핑
MCP 서버가 활성 상태인지 확인하기 위한 간단한 ping 엔드포인트
현재 사용자
현재 인증된 사용자에 대한 정보를 반환합니다.
사용자 목록
모든 사용자와 해당 역할의 목록을 반환합니다.
리스트_인덱스
접근 가능한 모든 Splunk 인덱스 목록을 반환합니다.
인덱스 정보 가져오기
특정 인덱스에 대한 자세한 정보를 반환합니다.
매개변수: index_name(문자열)
인덱스 및 소스 유형
인덱스와 해당 소스 유형의 포괄적인 목록을 반환합니다.
검색_스플렁크
Splunk 검색 쿼리를 실행합니다.
매개변수:
search_query(문자열): Splunk 검색 문자열
earliest_time(문자열, 선택 사항): 검색 창의 시작 시간
latest_time(문자열, 선택 사항): 검색 창의 종료 시간
max_results(정수, 선택 사항): 반환할 최대 결과 수
저장된 검색 목록
Splunk 인스턴스에 저장된 검색 목록을 반환합니다.
목록_kvstore_collections
모든 KV 매장 컬렉션을 나열합니다
create_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/Cloud 인스턴스
필요한 권한이 있는 적절한 Splunk 자격 증명
저장소를 복제합니다.
지엑스피1
Poetry를 사용하여 종속성을 설치합니다.
poetry install예제 환경 파일을 복사하고 설정을 구성하세요.
cp .env.example .envSplunk 자격 증명으로 .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 비밀을 사용하는 것을 고려하세요
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이 프로젝트에는 라이브 SSE 엔드포인트에 연결하고 모든 도구를 테스트하는 사용자 지정 MCP 클라이언트 테스트 스크립트가 포함되어 있습니다.
# 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 이벤트를 처리하여 도구 결과 추출
예상 형식에 대한 결과 검증
이는 실제 MCP 클라이언트에서 사용되는 SSE 인터페이스에 대한 실제 테스트를 제공합니다.
이 프로젝트에서는 세 가지 상호 보완적인 테스트 접근 방식을 사용합니다.
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를 Claude Desktop과 통합하려면 SSE 또는 STDIO 모드를 사용하도록 설정하세요. 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 systemKV 매장 관리:
List all KV store collectionsMCP 도구는 Claude에게 자동으로 제공되어 자연어 명령을 통해 이러한 작업을 실행할 수 있습니다.
[여기에 라이센스가 있습니다]
FastMCP 프레임워크
Python용 Splunk SDK
구성 관리를 위한 Python 분리
SSE 구현을 위한 SSE Starlette
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.
