用于访问和可视化 SolarWinds 可观测性日志的模型上下文协议 (MCP) 服务器。
此服务器目前尚未完善，因为它不支持结构化数据搜索（这是 REST API 的限制吗？）。我不确定它是否也需要接受一个数据中心用于 API 端点调用。时间允许的话会解决这两个问题（实际工作中需要用到，所以得先解决这个问题）。
使用可选筛选功能搜索 SolarWinds Observability 日志
采用搜索参数，包括过滤器、时间范围和分页选项
返回带有时间戳、主机名和消息的格式化日志条目
支持按组、实体等进行高级过滤
默认搜索范围为最近 24 小时
为日志事件生成直方图 JSON 响应
为克劳德和画布表现形式格式化
可配置的时间间隔（分钟、小时、天）
支持 UTC 或当地时区
可定制的查询过滤器和时间范围
默认可视化范围是过去 24 小时
URI 模板： solarwinds://{query}/search
返回与指定查询匹配的日志条目
例如： solarwinds://error/search
Related MCP server: Log Analyzer MCP Server
可选择从 npm 安装：
npm install -g mcp-solarwinds或者从源代码克隆并构建：
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 服务器需要 API 令牌来通过 SolarWinds Observability API 进行身份验证。
有多种方法可以提供 API 令牌：
MCP 设置配置（推荐） ：在 MCP 设置文件中配置令牌
环境变量：设置SOLARWINDS_API_TOKEN环境变量
本地 .env 文件（用于测试） ：在项目根目录中创建一个.env文件，其中包含SOLARWINDS_API_TOKEN=your-token
对于本地测试，您可以：
将.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
}Claude可视化（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 build由于 MCP 服务器通过 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.js使用 TypeScript 和 MCP SDK 构建
使用 axios 进行 API 通信
支持 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.
