SolarWinds Observability 로그에 액세스하고 시각화하기 위한 MCP(Model Context Protocol) 서버입니다.
이 서버는 구조화된 데이터 검색을 지원하지 않아 현재 불완전합니다(REST API의 한계인가요?). API 엔드포인트 호출에 사용할 데이터 센터도 허용해야 하는지 확실하지 않습니다. 시간이 허락하는 대로 두 가지 모두 해결하겠습니다(실제 업무 문제에 필요했기 때문에 먼저 해결해야 합니다).
선택적 필터링을 사용하여 SolarWinds Observability 로그 검색
필터, 시간 범위, 페이지 매김 옵션을 포함한 검색 매개변수를 사용합니다.
타임스탬프, 호스트 이름 및 메시지가 포함된 형식화된 로그 항목을 반환합니다.
그룹, 엔터티 등을 기준으로 고급 필터링을 지원합니다.
기본 검색 범위는 지난 24시간입니다.
로그 이벤트에 대한 히스토그램 JSON 응답을 생성합니다.
Claude 및 캔버스 표현에 맞게 포맷됨
구성 가능한 시간 간격(분, 시간, 일)
UTC 또는 현지 시간대를 지원합니다
사용자 정의 가능한 쿼리 필터 및 시간 범위
기본 시각화 범위는 지난 24시간입니다.
URI 템플릿: solarwinds://{query}/search
지정된 쿼리와 일치하는 로그 항목을 반환합니다.
예: solarwinds://error/search
Related MCP server: Log Analyzer MCP Server
선택적으로 npm에서 설치:
지엑스피1
또는 소스에서 복제하고 빌드합니다.
git clone https://github.com/@jakenuts/mcp-solarwinds.git
cd mcp-solarwinds
npm install
npm run build또는 구성에서 npx를 사용하세요.
%APPDATA%/Code - Insiders/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json 에 추가:
{
"mcpServers": {
"solarwinds": {
"command": "npx",
"args": ["-y", "mcp-solarwinds"],
"env": {
"SOLARWINDS_API_TOKEN": "your-api-token"
},
"autoApprove": ["search_logs", "visualize_logs"]
}
}
}적절한 구성 파일에 추가:
Windows: %APPDATA%/Claude/claude_desktop_config.json MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"solarwinds": {
"command": "npx",
"args": ["-y", "mcp-solarwinds"],
"env": {
"SOLARWINDS_API_TOKEN": "your-api-token"
}
}
}
}Windows에서 ENOENT spawn npx 문제가 발생하면 전체 경로를 지정하는 다음 대체 구성을 사용하세요.
{
"mcpServers": {
"solarwinds": {
"command": "C:\\Users\\[username]\\AppData\\Roaming\\nvm\\[node-version]\\node.exe",
"args": [
"C:\\Users\\[username]\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npx-cli.js",
"-y",
"mcp-solarwinds"
],
"env": {
"SOLARWINDS_API_TOKEN": "your-api-token"
}
}
}
}SolarWinds Observability MCP 서버에는 SolarWinds Observability API를 인증하기 위한 API 토큰이 필요합니다.
API 토큰을 제공하는 방법은 여러 가지가 있습니다.
MCP 설정 구성(권장) : MCP 설정 파일에서 토큰을 구성합니다.
환경 변수 : SOLARWINDS_API_TOKEN 환경 변수를 설정합니다.
로컬 .env 파일(테스트용) : SOLARWINDS_API_TOKEN=your-token 으로 프로젝트 루트에 .env 파일을 만듭니다.
로컬 테스트를 위해 다음을 수행할 수 있습니다.
.env.example``.env 로 복사하고 토큰을 추가하세요.
예제 스크립트를 실행합니다: node examples/local-test.js
기본 검색:
{
"filter": "error"
}시간 범위 및 페이지 번호를 사용한 고급 검색:
{
"filter": "error",
"entityId": "web-server",
"startTime": "2025-03-01T00:00:00Z",
"endTime": "2025-03-05T23:59:59Z",
"pageSize": 100,
"direction": "backward"
}기본 히스토그램(ASCII 차트):
{
"filter": "error",
"interval": "hour"
}고급 시각화(ASCII 차트):
{
"filter": "error",
"entityId": "web-server",
"startTime": "2025-03-01T00:00:00Z",
"endTime": "2025-03-05T23:59:59Z",
"interval": "day",
"use_utc": true
}클로드 시각화(JSON 형식):
{
"filter": "error",
"interval": "hour",
"format": "json"
}JSON 형식은 Claude가 차트로 시각화할 수 있는 데이터를 반환합니다.
{
"timeRanges": ["12:02", "12:03", "12:04", "12:05", "12:06", "12:07", "12:08", "12:09"],
"counts": [261, 47, 48, 48, 31, 262, 270, 33],
"total": 1000,
"queryParams": {
"query": "error",
"startTime": "2025-03-05T00:00:00.000Z",
"endTime": "2025-03-05T23:59:59.000Z"
}
}종속성 설치:
npm install서버를 빌드하세요:
npm run buildMCP 서버는 stdio를 통해 통신하기 때문에 디버깅이 어려울 수 있습니다. MCP Inspector는 다음과 같은 유용한 디버깅 도구를 제공합니다.
npm run debug:inspector이렇게 하면 브라우저에서 검사기에 액세스할 수 있는 URL이 제공되며, 이를 통해 다음을 수행할 수 있습니다.
모든 MCP 메시지 보기
요청/응답 페이로드 검사
테스트 도구를 대화형으로
서버 상태 모니터링
MCP 프레임워크 없이 로컬 테스트를 수행하는 경우:
# Create a .env file with your token
cp .env.example .env
# Edit .env to add your token
# Run the example script
node examples/local-test.jsTypeScript 및 MCP SDK로 구축됨
API 통신을 위해 Axios를 사용합니다.
시간 범위에 대한 ISO 8601 날짜 형식을 지원합니다.
로그 시각화를 위한 ASCII 히스토그램을 생성합니다.
기본 검색 범위: 지난 24시간
기본 페이지 크기: 50개 로그
다양한 인증 방식 지원
Search SolarWinds Observability logs with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | A search query string. Use AND/OR operators to combine terms (e.g., "error AND timeout"). The search is performed across all fields including message, hostname, program, and nested JSON fields like Context.CorrelationId. Field-specific queries like "field:value" are not supported. | |
| group | No | Filter logs by a specific group name | |
| entityId | No | Filter logs by a specific entity ID | |
| startTime | No | UTC start time (ISO 8601 format) | |
| endTime | No | UTC end time (ISO 8601 format) | |
| direction | No | Sort order: backward (oldest to newest), forward (newest to oldest), or tail (oldest to newest) | backward |
| pageSize | No | Maximum messages to return per page | |
| skipToken | No | Token to skip to the next page of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches logs with filtering, but lacks details on permissions, rate limits, pagination behavior (beyond schema hints), or what the response looks like (e.g., format, error handling). For a search tool with 8 parameters and no annotation coverage, this is insufficient.
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 front-loads the core purpose ('search SolarWinds Observability logs') and adds a key feature ('optional filtering'). There's no wasted text, and it's appropriately sized for the tool's complexity.
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 (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like pagination, error handling, or response format, which are crucial for effective use. The schema covers parameters well, but the description fails to provide necessary context for a search operation.
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 schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema, such as examples of complex queries or practical usage tips. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra insights.
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 ('search') and resource ('SolarWinds Observability logs'), making the purpose evident. However, it doesn't explicitly differentiate from the sibling 'visualize_logs' tool, which likely serves a different purpose (visualization vs. searching). The mention of 'optional filtering' adds some specificity but could be more distinct.
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, such as the sibling 'visualize_logs'. It mentions 'optional filtering' but doesn't specify scenarios where filtering is necessary or when other tools might be more appropriate. There's no explicit when/when-not or alternative usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a histogram visualization of log events
| Name | Required | Description | Default |
|---|---|---|---|
| interval | No | Time interval for histogram buckets | hour |
| startTime | No | UTC start time (ISO 8601 format), defaults to 24 hours ago | |
| endTime | No | UTC end time (ISO 8601 format), defaults to current time | |
| filter | No | A search query string | |
| group | No | Filter logs by a specific group name | |
| entityId | No | Filter logs by a specific entity ID | |
| pageSize | No | Maximum messages to analyze | |
| use_utc | No | Use UTC time instead of local time | |
| format | No | Output format: text for ASCII chart, json for Claude visualization | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a visualization but doesn't describe what happens during execution (e.g., whether it processes data in real-time, accesses a database, has rate limits, requires specific permissions, or returns an image or text). For a tool with 9 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving optimal conciseness.
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 complexity (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like execution details, return format (beyond implied visualization), or error handling. For a visualization tool with multiple filtering options, more context is needed to guide effective use.
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 no parameter-specific information beyond what's already in the input schema, which has 100% description coverage. It doesn't explain how parameters like 'filter' or 'group' affect the histogram or provide context for their usage. With high schema coverage, the baseline is 3, as the schema does the heavy lifting without additional value from the description.
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: 'Generate a histogram visualization of log events.' It specifies the action (generate), resource (histogram visualization), and target (log events). However, it doesn't explicitly differentiate from its sibling tool 'search_logs' beyond the visualization aspect, which is why it doesn't reach 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 its sibling 'search_logs' or any alternatives. There's no mention of use cases, prerequisites, or exclusions. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.
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.
v1.0.0search_logsvisualize_logsScored across 2 tools
The two tools have clearly distinct purposes: one searches logs with filtering, and the other generates visualizations. There is no overlap in functionality, making it impossible to confuse them.
Both tools follow a consistent verb_noun pattern (search_logs, visualize_logs) with the same naming style. This predictability helps agents understand the tool set structure easily.
With only two tools, the server feels too thin for a logs domain, lacking essential operations like creating, updating, or deleting logs. This minimal set limits agent capabilities significantly.
The tool set is severely incomplete for logs management, missing core CRUD operations and lifecycle coverage. Agents can only search and visualize, with no ability to modify or manage log data, leading to dead ends in workflows.
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
MCP observability. Query live traffic, errors, duration, and alerts from your AI agent.
