SolarWinds Observability ログにアクセスして視覚化するための Model Context Protocol (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 サーバーでは、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.
