What can you do with this server?

The SolarWinds Logs MCP Server is a tool for accessing and visualizing SolarWinds Observability logs with the following capabilities: * Search Logs: * Perform basic or advanced searches with filter query strings across message, hostname, program, and nested JSON fields using AND/OR operators * Filter by specific group or entity ID * Define custom time ranges using ISO 8601 timestamps (default: last 24 hours) * Paginate results with configurable page size, skip token, and sort direction options * Visualize Logs: * Generate histograms of log events with configurable time intervals (minute, hour, day) * Output in ASCII charts (text format) or JSON data for visualization tools like Claude * Control time zone display (UTC or local time) * Authentication: * Use SolarWinds API token via MCP settings, environment variables, or a local .env file

Which integrations are available for this server?

Supports local testing via .env files for storing API tokens and configuration Built with TypeScript for type safety and better development experience

How do I use SolarWinds Logs MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SolarWinds Logs MCP Server show me error logs from the last hour" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

SolarWinds Logs MCP Server

by jakenuts

Overview Schema Related Servers Score Discussions

TypeScript

Remote

SolarWinds Logs MCP Server

A Model Context Protocol (MCP) server for accessing and visualizing SolarWinds Observability logs.

Note -

This server is currently incomplete as it does not support structured data search (a limitation of the REST API?). I'm uncertain if it also needs to accept a data center to use in the api endpoint calls. Will address both when time allows (needed it for a real work problem, have to fix that first)

Tools

search_logs

Search SolarWinds Observability logs with optional filtering

Takes search parameters including filter, time range, and pagination options
Returns formatted log entries with timestamps, hostnames, and messages
Supports advanced filtering by group, entity, and more
Default search range is the last 24 hours

visualize_logs

Generate a histogram json response for of log events

Formatted for Claude and canvas representations
Configurable time intervals (minute, hour, day)
Supports UTC or local time zones
Customizable query filters and time ranges
Default visualization range is the last 24 hours

Resources

SolarWinds Log Search

URI Template: solarwinds://{query}/search
Returns log entries matching the specified query
Example: solarwinds://error/search

Related MCP server: Log Analyzer MCP Server

Installation

Optionally install from npm:

npm install -g mcp-solarwinds

Or clone and build from source:

git clone https://github.com/@jakenuts/mcp-solarwinds.git
cd mcp-solarwinds
npm install
npm run build

Or just use npx in your configurations

For Cline VSCode Extension

Add to %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"]
    }
  }
}

For Claude Desktop

Add to the appropriate config file:

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"
      }
    }
  }
}

Special Windows Configuration

If you encounter the ENOENT spawn npx issue on Windows, use this alternative configuration that specifies the full paths:

{
  "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"
      }
    }
  }
}

Configuration

The SolarWinds Observability MCP server requires an API token to authenticate with the SolarWinds Observability API.

Configuration Methods

There are multiple ways to provide the API token:

MCP Settings Configuration (Recommended): Configure the token in your MCP settings file
Environment Variable: Set the SOLARWINDS_API_TOKEN environment variable
Local .env File (For Testing): Create a .env file in the project root with SOLARWINDS_API_TOKEN=your-token

For local testing, you can:

Copy .env.example to .env and add your token
Run the example script: node examples/local-test.js

Tool Usage Examples

search_logs

Basic search:

{
  "filter": "error"
}

Advanced search with time range and pagination:

{
  "filter": "error",
  "entityId": "web-server",
  "startTime": "2025-03-01T00:00:00Z",
  "endTime": "2025-03-05T23:59:59Z",
  "pageSize": 100,
  "direction": "backward"
}

visualize_logs

Basic histogram (ASCII chart):

{
  "filter": "error",
  "interval": "hour"
}

Advanced visualization (ASCII chart):

{
  "filter": "error",
  "entityId": "web-server",
  "startTime": "2025-03-01T00:00:00Z",
  "endTime": "2025-03-05T23:59:59Z",
  "interval": "day",
  "use_utc": true
}

Claude visualization (JSON format):

{
  "filter": "error",
  "interval": "hour",
  "format": "json"
}

The JSON format returns data that Claude can visualize as a chart:

{
  "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"
  }
}

Development

Install dependencies:

npm install

Build the server:

npm run build

Debugging

Since MCP servers communicate over stdio, debugging can be challenging. The MCP Inspector provides helpful debugging tools:

npm run debug:inspector

This will provide a URL to access the inspector in your browser, where you can:

View all MCP messages
Inspect request/response payloads
Test tools interactively
Monitor server state

For local testing without the MCP framework:

# 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

Technical Details

Built with TypeScript and the MCP SDK
Uses axios for API communication
Supports ISO 8601 date formats for time ranges
Generates ASCII histograms for log visualization
Default search range: last 24 hours
Default page size: 50 logs
Supports multiple authentication methods

Available Tools

2 tools

search_logsC

Search SolarWinds Observability logs with optional filtering

ParametersJSON Schema

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

TDQS

C2.9/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

visualize_logsC

Generate a histogram visualization of log events

ParametersJSON Schema

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

TDQS

C2.9/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AgentCat
com.agentcat
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
Monitoring Observability
2
Foam Observability
io.github.foam-ai
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
Observability Monitoring Developer Tools
2
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
Spanly
com.spanly
MCP observability. Query live traffic, errors, duration, and alerts from your AI agent.
Observability Monitoring
3

Related MCP Servers

Mezmo MCP Server
Monitoring Observability
riefer02
F
license
Not graded
quality
D
maintenance
An MCP server for retrieving and filtering logs from Mezmo with a quota-conscious design and intelligent defaults. It enables users to discover and query logs by application, level, and custom time ranges to streamline debugging while minimizing API usage.
Updated 6 months ago (2026-03-03 18:19 UTC)
1
Log Analyzer MCP Server
RAG Systems Vector Databases Monitoring
suriya-ML
A
license
Not graded
quality
D
maintenance
An MCP server for intelligent log analysis providing semantic search, error pattern clustering, and smart error detection. It enables users to process, vectorize, and query local logs to efficiently identify issues and generate AI-powered summaries.
Updated 8 months ago (2025-12-19 16:37 UTC)
MIT
grafana-mcp
Monitoring Observability Search
ninanung
A
license
Not graded
quality
D
maintenance
This MCP server enables natural-language querying of Grafana logs by automatically detecting log sources and service labels. It provides read-only access to log data with intelligent caching for efficient repeat queries.
Updated 5 months ago (2026-04-16 01:48 UTC)
35
MIT
vmware-aria-logs
Monitoring Observability
apollion69
A
license
A
quality
D
maintenance
MCP server for querying and analyzing logs from VMware Aria Operations for Logs, enabling log search, incident detection, and vROps correlation.
Updated 5 months ago (2026-04-06 11:02 UTC)
6
4
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jakenuts/mcp-solarwinds'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SolarWinds Logs MCP Server

Note -

Tools

search_logs

visualize_logs

Resources

SolarWinds Log Search

Installation

For Cline VSCode Extension

For Claude Desktop

Special Windows Configuration

Configuration

Configuration Methods

Tool Usage Examples

search_logs

visualize_logs

Development

Debugging

Technical Details

Available Tools

TDQS

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Mezmo MCP Server

Log Analyzer MCP Server

grafana-mcp

vmware-aria-logs

Appeared in Searches

Latest Blog Posts

MCP directory API