lm-mcp
Advanced tools
Model Context Protocol (MCP) server for LogicMonitor REST API v3 integration. Enables AI assistants to interact with LogicMonitor monitoring data through 302 structured tools, 15 workflow prompts, and 26 resources. Optional integrations: IBM watsonx.ai for Granite TTM forecasting and NL summaries, Terraform IaC for any provider, and HuggingFace local Granite model fallback.
Works with any MCP-compatible client: Claude Desktop, Claude Code, Cursor, Continue, Cline, and more.
1. Get your LogicMonitor Bearer Token:
2. Configure your MCP client:
For Claude Code (CLI):
claude mcp add logicmonitor \
-e LM_PORTAL=yourcompany.logicmonitor.com \
-e LM_BEARER_TOKEN=your-bearer-token \
-- uvx --from lm-mcp lm-mcp-server
With IBM watsonx.ai integration (optional -- adds Granite TTM forecasting and NL summaries):
claude mcp add logicmonitor \
-e LM_PORTAL=yourcompany.logicmonitor.com \
-e LM_BEARER_TOKEN=your-bearer-token \
-e WATSONX_API_KEY=your-ibm-cloud-api-key \
-e WATSONX_URL=https://us-south.ml.cloud.ibm.com \
-e WATSONX_PROJECT_ID=your-watsonx-project-id \
-- uvx --from "lm-mcp[ibm]" lm-mcp-server
With Terraform IaC (optional -- adds terraform plan/apply/generate tools):
claude mcp add logicmonitor \
-e LM_PORTAL=yourcompany.logicmonitor.com \
-e LM_BEARER_TOKEN=your-bearer-token \
-e TF_WORKSPACE_DIR=/path/to/terraform/workspaces \
-- uvx --from lm-mcp lm-mcp-server
With HuggingFace local models (optional -- local Granite TTM + NL summaries, no cloud API needed):
claude mcp add logicmonitor \
-e LM_PORTAL=yourcompany.logicmonitor.com \
-e LM_BEARER_TOKEN=your-bearer-token \
-- uvx --from "lm-mcp[huggingface]" lm-mcp-server
For Claude Desktop, add to your config file (see MCP Client Configuration below).
3. Verify it's working:
claude mcp list
You should see: logicmonitor: uvx --from lm-mcp lm-mcp-server - ✓ Connected
4. Test with a prompt:
"Show me all critical alerts in LogicMonitor"
Native OTLP metrics arrive. LogicMonitor's new OTLP Metrics feature (feature-flag
gated, Prometheus-backed) ships in its first phase with a single UI surface (the
dashboard Advanced Metrics Widget) and no Metrics Explorer yet; these four tools
are the first programmatic window into that data: get_otlp_metric_names,
get_otlp_metric_labels, and get_otlp_label_values for discovery, and
query_otlp_metrics for full PromQL range queries returning time-series matrices.
All four were validated live against a flag-enabled portal fed by a real OTel
collector (Kubernetes cAdvisor and application metrics), translate the
feature-disabled portal responses into a clear availability notice, and cap large
matrix responses with even-stride downsampling so they stay LLM-friendly.
Major. Every tool now wraps an endpoint proven to exist, validated against a live
portal. Six tools that called nonexistent API paths since introduction are removed
(get_cloud_cost_accounts, get_cost_summary, get_resource_cost,
get_remediation_status, get_remediation_history, get_batchjob_history); the cost
recommendation tools move onto the working /cost-optimization API; the Service Insight
tools query real Service Insight objects (deviceType 6 devices and BizService groups)
instead of the legacy v1 websites API. The Automated Diagnostics & Remediation surface
arrives in full: get_diagnostic_remediation_assignments and
get_diagnostic_remediation_results (structured execution records with script output,
replacing audit-log scraping), execute_diagnostic, full CRUD plus import/export for
diagnostic and remediation sources, and the new action chain / action rule namespace
(11 tools including the set_action_rule_status toggle). update_logicmodule gains the
two new source types and its apply mode actually applies now (it previously tripped its
own sub-tools' confirm guards). run_report executions are pollable via
get_report_execution, get_alert_details can fetch the full message body, and NextGen
reports are visible to the report list tools.
Full release history, including v3.9.x and earlier, is in CHANGELOG.md. The v3.8.0 networking intelligence tools have a dedicated reference: documentation/networking-intelligence.md.
302 Tools across comprehensive LogicMonitor API coverage (273 LM + 18 AAP + 10 Terraform + 1 watsonx):
Server-side intelligence that transforms raw monitoring data into actionable insights:
Pure-Python statistical methods for capacity planning, trend analysis, and operational scoring:
Multi-step analysis tools that combine several sub-tools into a single call. Each supports detail_level ("summary" or "full"), optional summarize=true for plain-English NL summaries via IBM Granite (requires watsonx.ai), and handles sub-tool failures gracefully with partial results.
update_logicmodule(type, id, changes, mode) exports the current full definition, deep-merges your changes, validates required fields, and returns a dry-run diff (default) or applies the merge. Prevents the full-replace blanking that wiped production Groovy scripts in two prior incidents. Supports configsource, datasource, eventsource, logsource, propertysource, topologysource.Service discovery and RED metrics for LogicMonitor APM (Application Performance Monitoring):
18 tools for observability-driven remediation via Ansible Automation Platform (AAP). Connects LogicMonitor alerts to automated remediation playbooks.
LM_ENABLE_WRITE_OPERATIONS=trueAAP tools are optional — they only appear when AWX_URL and AWX_TOKEN are configured. See Example Playbooks for remediation templates.
Optional AI-powered enhancements using IBM Granite foundation models via watsonx.ai. Requires an IBM Cloud account with a watsonx.ai project (Lite/free tier supported).
method="ttm" on forecast_metric for 96-step predictions that detect seasonality and non-linear patterns. Requires 512+ data points. Gracefully falls back to statistical methods when data is insufficient.triage, diagnose, health_check, capacity_plan, portal_overview). Pass summarize=true to append an IBM Granite-generated analysis summary to the structured output.watsonx tools are optional — they only appear when WATSONX_API_KEY and WATSONX_PROJECT_ID are configured. Install with lm-mcp[ibm] to include the IBM SDK dependencies.
Setup:
WATSONX_API_KEY, WATSONX_URL, and WATSONX_PROJECT_ID11 tools for Infrastructure as Code workflows with any Terraform provider. AI agents can author HCL, use pre-made scripts, or reverse-engineer existing LM resources.
logicmonitor/logicmonitor providerTerraform tools are optional -- they only appear when TF_WORKSPACE_DIR is configured. Requires the terraform CLI installed separately.
Three entry points:
TF_WORKSPACE_DIR at existing .tf files, agent operates on themterraform_generate exports LM resources as HCL, then import into stateWhen watsonx.ai API credentials are not configured, TTM forecasting and NL summaries automatically fall back to local Granite models via HuggingFace transformers. Install with lm-mcp[huggingface].
Priority chain: watsonx.ai API (remote) > HuggingFace local > statistical/linear
ibm-granite/granite-timeseries-ttm-r2 (512 context, 96 forecast)ibm-granite/granite-3.3-2b-instruct (2B params, runs on CPU)Pre-built slash-command workflows for Claude Code that orchestrate multiple tools into guided operational runbooks:
| Skill | Command | Description |
|---|---|---|
| Alert Triage | /lm-triage | Investigate active alerts, score noise, correlate clusters, assess blast radius, take action |
| Device Health | /lm-health <device> | Comprehensive health check — metrics, anomalies, health score, availability, topology |
| Portal Overview | /lm-portal | Portal-wide snapshot for shift handoff — alerts, collectors, SDTs, down devices |
| Capacity Planning | /lm-capacity <device> | Trend analysis, seasonality detection, breach forecasting, right-sizing |
| APM Investigation | /lm-apm [service] | Service discovery, operation-level RED metrics, alert correlation |
| Remediation | /lm-remediate | Diagnose alert, find/generate playbook, launch AAP job, verify fix |
Skills ship with the repo — clone it and invoke /lm-triage in Claude Code to get started.
# Using uvx (no install needed)
uvx --from lm-mcp lm-mcp-server
# Using pip
pip install lm-mcp
git clone https://github.com/ryanmat/mcp-server-logicmonitor.git
cd mcp-server-logicmonitor
uv sync
For remote/shared deployments using HTTP transport:
cd deploy
cp .env.example .env
# Edit .env with your credentials
# Run with docker-compose
docker compose up -d
# With TLS via Caddy
docker compose --profile tls up -d
The server exposes health endpoints for container orchestration:
GET /health - Detailed health check with all component statusesGET /healthz - Liveness probe (200 OK or 503)GET /readyz - Readiness probe (includes connectivity check if enabled)| Variable | Required | Default | Description |
|---|---|---|---|
LM_PORTAL | Yes | - | LogicMonitor portal hostname (e.g., company.logicmonitor.com) |
LM_BEARER_TOKEN | Yes* | - | API Bearer token (min 10 characters) |
LM_ACCESS_ID | No | - | LMv1 API access ID (for ingestion APIs) |
LM_ACCESS_KEY | No | - | LMv1 API access key (for ingestion APIs) |
LM_ENABLE_WRITE_OPERATIONS | No | false | Enable write operations (create, update, delete) |
LM_API_VERSION | No | 3 | API version |
LM_TIMEOUT | No | 30 | Request timeout in seconds (range: 5-300) |
LM_MAX_RETRIES | No | 3 | Max retries for rate-limited/server error requests (range: 0-10) |
LM_TRANSPORT | No | stdio | Transport mode: stdio (local) or http (remote) |
LM_HTTP_HOST | No | 0.0.0.0 | HTTP server bind address |
LM_HTTP_PORT | No | 8080 | HTTP server port |
LM_CORS_ORIGINS | No | * | Comma-separated CORS origins |
LM_SESSION_ENABLED | No | true | Enable session context tracking |
LM_SESSION_HISTORY_SIZE | No | 50 | Number of tool calls to keep in history |
LM_LOG_LEVEL | No | warning | Logging level: debug, info, warning, or error |
LM_FIELD_VALIDATION | No | warn | Field validation: off, warn, or error |
LM_ENABLED_TOOLS | No | - | Comma-separated tool names or glob patterns to enable (e.g., get_*,triage). Mutually exclusive with LM_DISABLED_TOOLS. |
LM_DISABLED_TOOLS | No | - | Comma-separated tool names or glob patterns to disable (e.g., delete_*). Mutually exclusive with LM_ENABLED_TOOLS. |
LM_MCP_CATEGORIES | No | - | Comma-separated category names to include: read, write, delete, export, import, session, workflow. Composes by intersection with LM_ENABLED_TOOLS/LM_DISABLED_TOOLS -- only narrows, never expands. Useful for clients with tool-count limits (e.g., Cursor's 40-tool cap). |
LM_HEALTH_CHECK_CONNECTIVITY | No | false | Include LM API ping in health checks |
LM_SESSION_PERSIST_PATH | No | - | File path for persistent session variables (survives restarts) |
LM_ANALYSIS_TTL_MINUTES | No | 60 | TTL for scheduled analysis results (1-1440 minutes) |
AWX_URL | No | - | Ansible Automation Platform controller URL (e.g., https://aap.example.com) |
AWX_TOKEN | No | - | AAP personal access token |
AWX_VERIFY_SSL | No | true | Verify SSL certificates for AAP connections |
AWX_TIMEOUT | No | 30 | Request timeout in seconds for AAP API calls |
AWX_MAX_RETRIES | No | 3 | Max retries for failed AAP API requests |
WATSONX_API_KEY | No | - | IBM Cloud API key for watsonx.ai (enables Granite TTM + NL summaries) |
WATSONX_URL | No | https://us-south.ml.cloud.ibm.com | IBM watsonx.ai endpoint URL |
WATSONX_PROJECT_ID | No | - | IBM watsonx.ai project ID |
WATSONX_TIMEOUT | No | 60 | Request timeout in seconds for watsonx.ai API calls |
TF_WORKSPACE_DIR | No | - | Root directory for Terraform workspaces (enables Terraform tools) |
TF_TERRAFORM_BINARY | No | terraform | Path to the terraform binary |
TF_TIMEOUT | No | 300 | Terraform command timeout in seconds |
TF_AUTO_APPROVE_ENABLED | No | false | Enable terraform apply/destroy operations |
HF_TTM_MODEL | No | ibm-granite/granite-timeseries-ttm-r2 | HuggingFace TTM model name or path |
HF_LLM_MODEL | No | ibm-granite/granite-3.3-2b-instruct | HuggingFace LLM model name or path |
HF_DEVICE | No | auto | Torch device for inference (cpu, cuda, mps, auto) |
HF_CACHE_DIR | No | - | HuggingFace model cache directory |
*Either LM_BEARER_TOKEN or both LM_ACCESS_ID and LM_ACCESS_KEY are required.
Bearer Token (Recommended):
LM_BEARER_TOKENLMv1 HMAC (Required for Ingestion):
ingest_logs and push_metrics toolsLM_ACCESS_ID and LM_ACCESS_KEYBearer Token:
LMv1 Credentials:
The Quick Start covers Claude Code. Every JSON-based client (Cursor, Claude Desktop, Cline, GitHub Copilot, Gemini CLI, OpenAI Codex) runs the same server with the same block:
{
"mcpServers": {
"logicmonitor": {
"command": "uvx",
"args": ["--from", "lm-mcp", "lm-mcp-server"],
"env": {
"LM_PORTAL": "yourcompany.logicmonitor.com",
"LM_BEARER_TOKEN": "your-bearer-token"
}
}
}
}
Add LM_ENABLE_WRITE_OPERATIONS, LM_ACCESS_ID/LM_ACCESS_KEY (ingestion), or the watsonx/Terraform variables to env as needed. Per-client config file locations and exact steps (Claude Code, Cursor, Claude Desktop, OpenAI Codex, Cline, GitHub Copilot, Gemini CLI) are in documentation/client-setup.md.
Cursor only loads the first 40 MCP tools, so the remaining ~240 are invisible to the agent. Use LM_MCP_CATEGORIES to fit a curated subset under the cap. The workflow category alone (triage, diagnose, health_check, portal_overview, capacity_plan, plus the scoring/correlation tools and update_logicmodule) is roughly 23 tools and covers the 80% case:
"env": {
"LM_PORTAL": "yourcompany.logicmonitor.com",
"LM_BEARER_TOKEN": "your-bearer-token",
"LM_MCP_CATEGORIES": "workflow"
}
LM_MCP_CATEGORIES composes with LM_ENABLED_TOOLS by intersection (it only narrows, never expands); unset, the server returns all 302 tools. See documentation/client-setup.md for a surgical LM_ENABLED_TOOLS example.
302 tools cover the full LogicMonitor surface plus the optional Ansible Automation Platform, Terraform, and IBM watsonx.ai integrations. The complete per-tool reference (every tool, its parameters, and its read/write classification) is in documentation/tools.md, generated from the tool registry so it never drifts.
Discover tools at runtime without leaving your client:
search_tools: keyword search across every tool by name and descriptionlm://guide/tool-categories resource: all 302 tools grouped by domainTools are organized into these categories: Alerts, Alert Rules, Devices, Metrics, APM Traces, Dashboards, SDT, Collectors, Websites, Escalations, Device Properties, Reports, DataSources, LogicModules (Config/Event/Property/Topology/Log), Cost Optimization, Actions (Chains & Rules), Ingestion, Network & Topology, Batch Jobs, Ops & Audit, Users & Access, Services, Netscans, OIDs, Session, Correlation & Analysis, Baselines, ML/Statistical Analysis, Ansible Automation Platform, Remediation, Composite Workflows, and Error Budget.
The server exposes 26 resources for API reference:
| URI | Description |
|---|---|
lm://schema/alerts | Alert object fields, types, and descriptions |
lm://schema/devices | Device object fields and types |
lm://schema/sdts | SDT (Scheduled Downtime) object fields |
lm://schema/dashboards | Dashboard object fields |
lm://schema/collectors | Collector object fields |
lm://schema/escalations | Escalation chain object fields |
lm://schema/reports | Report object fields |
lm://schema/websites | Website check object fields |
lm://schema/datasources | DataSource definition fields |
lm://schema/users | User object fields |
lm://schema/audit | Audit log entry fields |
| URI | Description |
|---|---|
lm://enums/severity | Alert severity levels: critical(4), error(3), warning(2), info(1) |
lm://enums/device-status | Device status values: normal(0), dead(1), etc. |
lm://enums/sdt-type | SDT types: DeviceSDT, DeviceGroupSDT, etc. |
lm://enums/alert-cleared | Alert cleared status: true, false |
lm://enums/alert-acked | Alert acknowledgment status: true, false |
lm://enums/collector-build | Collector build types: EA, GD, MGD |
| URI | Description |
|---|---|
lm://filters/alerts | Filter fields and operators for alert queries |
lm://filters/devices | Filter fields and operators for device queries |
lm://filters/sdts | Filter fields and operators for SDT queries |
lm://syntax/operators | Filter operators: :, ~, >, <, !:, !~, >:, <: |
| URI | Description |
|---|---|
lm://guide/tool-categories | All 302 tools organized by domain category |
lm://guide/examples | Common filter patterns and query examples |
lm://guide/mcp-orchestration | Patterns for combining LogicMonitor with other MCP servers |
lm://guide/best-practices | Scenario-based best practices with recommendations and anti-patterns |
lm://guide/example-responses | Example output for key tools to help understand response formats |
Pre-built workflow templates for common tasks:
| Prompt | Description | Arguments |
|---|---|---|
incident_triage | Analyze active alerts, identify patterns, suggest root cause | severity, time_window_hours |
capacity_review | Review resource utilization and identify capacity concerns | group_id, threshold_percent |
health_check | Generate environment health summary with key metrics | include_collectors |
alert_summary | Generate alert digest grouped by severity or resource | group_by, hours_back |
sdt_planning | Plan scheduled downtime for maintenance windows | device_ids, group_id |
cost_optimization | Analyze cloud costs, find savings opportunities | provider, threshold_percent |
audit_review | Review recent changes, logins, and security events | hours_back, username |
alert_correlation | Correlate alerts across devices to find common root causes | severity, hours_back, device_id, group_id |
collector_health | Assess collector load balancing, versions, and failover readiness | group_id |
troubleshoot_device | Guided troubleshooting for a specific device | device_id |
top_talkers | Identify noisiest devices and datasources generating the most alerts | hours_back, limit, group_by |
rca_workflow | Guided root cause analysis combining alerts, topology, and change history | device_id, alert_id, hours_back |
capacity_forecast | Forecast capacity trends and predict threshold breaches | device_id, group_id, datasource, hours_back, threshold |
remediate_workflow | Diagnose a LogicMonitor alert and remediate via Ansible Automation Platform | alert_id, device_id |
remediation | Execute a LogicMonitor remediation source with pre-execution safety checks | host_id, remediation_source_id |
Once configured, ask your assistant in natural language. A representative sample (the server understands far more across all 302 tools):
For power users, the server accepts LogicMonitor filter syntax directly, for example "Get devices where filter is 'displayName~prod,hostStatus:alive'".
uv run pytest -v
uv run ruff check src tests
uv run ruff format src tests
src/lm_mcp/
├── __init__.py # Package exports
├── analysis.py # Scheduled analysis workflows and store
├── awx_config.py # AAP connection configuration
├── config.py # Environment-based configuration
├── exceptions.py # Exception hierarchy
├── health.py # Health check endpoints
├── logging.py # Structured logging
├── server.py # MCP server entry point
├── session.py # Session context with optional persistence
├── registry.py # Tool definitions and handlers (TOOLS + AWX_TOOLS)
├── validation.py # Field validation with suggestions
├── auth/
│ ├── __init__.py # Auth provider factory
│ ├── bearer.py # Bearer token auth
│ └── lmv1.py # LMv1 HMAC auth
├── client/
│ ├── __init__.py # Client exports
│ ├── api.py # Async HTTP client for LogicMonitor API
│ └── awx.py # Async HTTP client for AAP controller API
├── completions/
│ └── registry.py # Auto-complete definitions
├── prompts/
│ ├── registry.py # Prompt definitions
│ └── templates.py # Workflow template content
├── resources/
│ ├── registry.py # Resource definitions
│ ├── schemas.py # Schema content
│ ├── enums.py # Enum content
│ ├── filters.py # Filter content
│ ├── guides.py # Tool categories, query examples, orchestration guide
│ ├── best_practices.py # Scenario-based best practices and anti-patterns
│ └── examples.py # Example responses for key tools
├── transport/
│ ├── __init__.py # Transport abstraction
│ └── http.py # HTTP/SSE transport with analysis endpoints
└── tools/
├── __init__.py # Tool utilities
├── alerts.py # Alert management
├── alert_rules.py # Alert rule CRUD
├── ansible.py # Ansible Automation Platform tool handlers
├── baselines.py # Metric baseline save/compare
├── collectors.py # Collector tools
├── correlation.py # Alert correlation, anomaly detection, metric correlation
├── cost.py # Cost optimization
├── dashboards.py # Dashboard CRUD
├── devices.py # Device CRUD
├── escalations.py # Escalation/recipient CRUD
├── event_correlation.py # Change-alert correlation
├── forecasting.py # Forecast, trend, seasonality, change points
├── imports.py # LogicModule import
├── ingestion.py # Log/metric ingestion
├── metrics.py # Metrics and data
├── scoring.py # Alert noise, availability, device health
├── sdts.py # SDT management
├── session.py # Session management tools
├── stats_helpers.py # Shared statistical math utilities (incl. Holt-Winters, IQR, MAD)
├── topology_analysis.py # Blast radius analysis
├── websites.py # Website CRUD
├── workflows.py # Composite workflow tools (triage, health_check, etc.)
├── metric_presets.py # Metric-type presets for auto-configuration
└── ... # Additional tool modules
examples/playbooks/
├── lm-remediate-disk-cleanup.yml
├── lm-remediate-service-restart.yml
├── lm-remediate-log-rotate.yml
└── lm-remediate-memory-cache-clear.yml
deploy/
├── Dockerfile # Production Docker image
├── docker-compose.yml # Full stack deployment
├── Caddyfile # TLS proxy configuration
└── .env.example # Environment template
If claude mcp list shows ✗ Failed to connect, the server is missing environment variables. The -e flags must be included when adding the server:
# Remove the broken config
claude mcp remove logicmonitor
# Re-add with environment variables
claude mcp add logicmonitor \
-e LM_PORTAL=yourcompany.logicmonitor.com \
-e LM_BEARER_TOKEN=your-bearer-token \
-- uvx --from lm-mcp lm-mcp-server
Note: Setting environment variables in your shell or
.envfile won't work—Claude Code spawns the MCP server as a subprocess with its own environment.
Write operations (acknowledge, create SDT, etc.) are disabled by default. Set LM_ENABLE_WRITE_OPERATIONS=true in your environment.
Claude Desktop can't find uvx. Use the full path:
{
"command": "/Users/yourname/.local/bin/uvx",
"args": ["--from", "lm-mcp", "lm-mcp-server"]
}
Find your uvx path with: which uvx
The ingest_logs and push_metrics tools require LMv1 authentication. Bearer tokens don't work with ingestion APIs. Add LM_ACCESS_ID and LM_ACCESS_KEY to your configuration.
The server automatically retries rate-limited requests with exponential backoff. If you're consistently hitting limits, reduce request frequency or contact LogicMonitor support.
Verify your bearer token is correct and has appropriate permissions. API tokens can be managed in LogicMonitor under Settings → Users and Roles → API Tokens.
MIT License - see LICENSE file.
FAQs
MCP server for LogicMonitor platform API integration
The pypi package lm-mcp receives a total of 179 weekly downloads. As such, lm-mcp popularity was classified as not popular.
We found that lm-mcp demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
During a UK cyber test, a Mythos 5 agent used sockpuppets, social engineering, and prompt injection to try to get a maintainer to merge malware.
Company News
Socket is now in the AWS Security Hub Extended plan. Adopt it through AWS, apply committed spend, and block malicious open source packages.
Research
/Security News
Popular npm packages keyv and cacheable compromised.