LogicMonitor MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LM_COMPANY | Yes | Your LogicMonitor company/account name (subdomain). Example: if your portal is mycompany.logicmonitor.com, use mycompany | |
| LM_BEARER_TOKEN | Yes | LogicMonitor API Bearer Token. Generate at: Settings > Users & Roles > API Tokens |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
| prompts | {} |
| resources | {} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_alert_linkA | Generate a direct URL/link/weburl for a LogicMonitor (LM) alert. Returns: Direct URL to alert details page. URL pattern: https://mycompany.logicmonitor.com/santaba/uiv4/alerts/{alertId} When to use:
Why use this: Simplifies alert investigation by providing direct navigation to the alert details page with full context, history, and acknowledgement options. Workflow: Get alertId from "list_alerts", then use this tool to generate the shareable link for team collaboration. Related tools: "list_alerts" (find alerts), "get_alert" (get details), "acknowledge_alert" (acknowledge). |
| generate_dashboard_linkA | Generate a direct URL/link/weburl for a LogicMonitor (LM) dashboard. Returns: Complete dashboard URL with full group hierarchy path, dashboard details (id, name, groupName), and group path array. URL pattern: https://mycompany.logicmonitor.com/santaba/uiv4/dashboards/dashboardGroups-{path},dashboards-{id} When to use:
Why use this: Provides the complete navigable URL including all parent group IDs, so the link opens the dashboard in correct context within the UI navigation tree. Workflow: First use "list_dashboards" to find dashboard ID, then use this tool to generate the shareable link. Related tools: "list_dashboards" (find dashboard), "get_dashboard" (get details). |
| generate_resource_linkA | Generate a direct URL/link/weburl for a LogicMonitor (LM) resource/device. Returns: Complete resource URL with full group hierarchy, resource/device details (id, name, displayName), and group path array. URL pattern: https://mycompany.logicmonitor.com/santaba/uiv4/resources/treeNodes?resourcePath=resourceGroups-{path},resources-{id} When to use:
Why use this: Provides the complete URL including all parent group IDs, so clicking the link navigates directly to the resource/device in the correct folder context. Workflow: First find resource/device using "list_resources" or "search_resources", then use this tool with deviceId to generate shareable link. Related tools: "list_resources" (find device), "get_resource" (get details), "generate_alert_link" (link to resource/device alerts). |
| generate_website_linkA | Generate a direct direct URL/link/weburl for a LogicMonitor (LM) website monitor with full hierarchy path for easy sharing and navigation. What this does: Creates shareable URL that opens specific website monitor in LogicMonitor UI, preserving the full folder hierarchy path. Link works for anyone with access to the LogicMonitor portal. Returns: Complete URL in format: https://mycompany.logicmonitor.com/santaba/uiv4/websites/treeNodes#websiteGroups-{groupId1},websiteGroups-{groupId2},...,websites-{websiteId} When to use:
Required parameters:
Common use cases: Share in Slack/Teams: "Production API health check is failing: View Monitor" Incident ticket documentation: "INC-12345: Website monitor showing SSL certificate expiring in 7 days. See: {generated-url}" Runbook links: "If homepage monitoring alerts, check: {generated-url-for-homepage-monitor}" Custom reporting: Build report that includes clickable links to each website monitor for quick access. Link structure explained: The URL includes complete folder path (websiteGroups) so when clicked, the UI shows:
Why use generated links:
Workflow example:
Access requirements: Link recipients must:
Best practices:
Related tools: "list_websites" (find website), "get_website" (verify details), "generate_dashboard_link" (for dashboards), "generate_resource_link" (for resources/devices), "generate_alert_link" (for alerts). |
| get_access_groupA | Get detailed information about a specific access group in LogicMonitor (LM) monitoring by its ID. Returns: Complete access group details: name, description, tenant ID, list of associated resources (which resources/devices/groups are in this access group), list of users assigned to this access group. When to use:
Key information returned:
Impact analysis: Before modifying access group:
Workflow: Use "list_access_groups" to find accessGroupId, then use this tool to review complete configuration before modifications. Related tools: "list_access_groups" (find groups), "update_access_group" (modify), "list_users" (see user access). |
| get_alertA | Get detailed information about a specific alert in LogicMonitor (LM) monitoring by its ID. Returns: Complete alert details: alert message, severity, threshold crossed, current value, alert history, escalation chain triggered, acknowledgement details, resource details, datasource/datapoint info, alert rule applied. When to use:
Workflow: First use "list_alerts" to find the alertId, then use this tool for complete investigation details. Related tools: "acknowledge_alert" (acknowledge alert), "add_alert_note" (document findings), "generate_alert_link" (share with team). |
| get_alert_ruleA | Get detailed information about a specific alert rule by ID in LogicMonitor (LM) monitoring. Returns: Complete alert rule details: name, priority, enabled status, detailed matching conditions (device groups, datasources, datapoints, instance filters, severity levels), escalation chain assignment, suppression windows, notification settings. When to use:
Matching conditions explained:
Troubleshooting use cases:
Workflow: Use "list_alert_rules" to find ruleId, then use this tool to review complete matching logic and routing. Related tools: "list_alert_rules" (find rules), "update_alert_rule" (modify), "get_escalation_chain" (check notification chain). |
| get_audit_logA | Get detailed information about a specific audit log entry in LogicMonitor (LM) monitoring by its ID. Returns: Complete audit log details: username, IP address, exact timestamp, full description of action, session ID, affected resources, before/after values (for updates). When to use:
Workflow: First use "list_audit_logs" with filters to find relevant entries, then use this tool with the log ID for complete details. Related tools: "list_audit_logs" (search logs), "search_audit_logs" (text search). |
| get_collectorA | Get detailed information about a specific collector by its ID in LogicMonitor (LM) monitoring. Returns: Complete collector details: description (name), hostname, platform, status, build version, number of resource/device monitored, free disk space, CPU/memory usage, last heartbeat, configuration. When to use:
Health indicators to check:
Workflow: Use "list_collectors" to find collectorId, then use this tool for detailed health check. Related tools: "list_collectors" (find collector), "list_collector_versions" (check updates), "list_resources" (see assigned resources/devices). |
| get_collector_groupA | Get detailed information about a specific collector group by ID in LogicMonitor (LM) monitoring. Returns: Complete collector group details: name, full path, parentId, description, number of collectors (direct and total), number of subgroups. When to use:
Workflow: Use "list_collector_groups" to find groupId, then use this tool for complete details. Related tools: "list_collector_groups" (find groups), "list_collectors" (collectors in group), "create_collector_group" (create new). |
| get_configsourceA | Get detailed information about a specific ConfigSource by its ID in LogicMonitor (LM) monitoring. Returns: Complete ConfigSource details: name, displayName, description, appliesTo logic (which resources/devices), collection method (CLI/SNMP/API), collection script, alert settings. When to use:
Key information:
Workflow: Use "list_configsources" to find configSourceId, then use this tool to understand how it works. Related tools: "list_configsources" (find ConfigSource), "list_device_configs" (see configs for device). |
| get_dashboardA | Get detailed information about a specific dashboard by its ID in LogicMonitor (LM) monitoring. Returns: Complete dashboard details: name, description, groupId, owner, widgets configuration, widget count, sharing settings, template variables, last modified. When to use:
What you get:
Use cases:
Workflow: Use "list_dashboards" to find dashboardId, then get details, then "generate_dashboard_link" to get shareable URL. Related tools: "list_dashboards" (find dashboard), "generate_dashboard_link" (get URL), "update_dashboard" (modify), "list_dashboard_groups" (browse folders). |
| get_dashboard_groupA | Get detailed information about a specific dashboard group by its ID in LogicMonitor (LM) monitoring. Returns: Complete dashboard group details: name, full path, parentId, description, number of dashboards (direct and total), number of subgroups, owner, permissions. When to use:
Workflow: Use "list_dashboard_groups" to find groupId, then use this tool for complete details. Related tools: "list_dashboard_groups" (find groups), "list_dashboards" (dashboards in group), "create_dashboard_group" (create new). |
| get_datasourceA | Get detailed information about a specific datasource by its ID in LogicMonitor (LM) monitoring. Returns: Complete datasource details: name, displayName, description, appliesTo logic, collection method, datapoints (metrics), thresholds, alert rules, polling interval. When to use:
Key information returned:
Understanding appliesTo logic: Shows why datasource does/doesn't monitor certain resources/devices. Common patterns:
Workflow: Use "list_datasources" to find dataSourceId, then use this tool to understand how it works. Related tools: "list_datasources" (find datasource), "list_resource_datasources" (see which resource/device use it). |
| get_escalation_chainA | Get detailed information about a specific escalation chain by its ID in LogicMonitor (LM) monitoring. Returns: Complete escalation chain details: name, description, all stages with: recipients at each stage, notification methods (email/SMS/webhook), time delays between stages, rate limiting, business hours restrictions. When to use:
Stage details returned: For each stage:
Example escalation chain details: Stage 1 (0 min): Email "oncall@company.com", SMS "+1-555-1234" Stage 2 (15 min): PagerDuty integration, Email "team-lead@company.com" Stage 3 (30 min): Slack webhook, Email "engineering-manager@company.com" Workflow: Use "list_escalation_chains" to find chainId, then use this tool to review complete notification workflow. Related tools: "list_escalation_chains" (find chains), "update_escalation_chain" (modify), "list_recipients" (see recipients). |
| get_eventsourceA | Get detailed information about a specific EventSource by its ID in LogicMonitor (LM) monitoring. Returns: Complete EventSource details: name, displayName, description, appliesTo logic, collection method, filter rules, severity mapping, alert settings. When to use:
Key information:
Workflow: Use "list_eventsources" to find eventSourceId, then use this tool for complete configuration. Related tools: "list_eventsources" (find EventSource), "list_device_eventsources" (events for device). |
| get_integrationA | Get detailed information about a specific integration by ID in LogicMonitor (LM) monitoring. Returns: Complete integration details: name, type, configuration (API keys, webhooks, URLs), authentication status, last successful notification, error logs, which escalation chains use it. When to use:
Configuration details by type:
Troubleshooting:
Workflow: Use "list_integrations" to find integrationId, then use this tool for detailed configuration and troubleshooting. Related tools: "list_integrations" (find integrations), "test_integration" (send test), "update_integration" (modify). |
| get_netscanA | Get detailed information about a specific netscan by ID in LogicMonitor (LM) monitoring. Returns: Complete netscan details: name, description, scan method, schedule, target networks/IPs, credentials, filters (include/exclude rules), resource/device properties to apply, collector assignment, duplicate detection settings, last execution results. When to use:
Configuration details returned:
Troubleshooting use cases:
Workflow: Use "list_netscans" to find netscanId, then use this tool to review complete configuration. Related tools: "list_netscans" (find netscan), "update_netscan" (modify), "run_netscan" (execute now). |
| get_opsnoteA | Get detailed information about a specific operational note by ID in LogicMonitor (LM) monitoring. Returns: Complete OpsNote details: note text, timestamp, creator, tags, scope (resources/devices/groups affected), related SDTs, linked resources. When to use:
Workflow: Use "list_opsnotes" to find note ID, then use this tool for complete details. Related tools: "list_opsnotes" (find notes), "create_opsnote" (add new), "update_opsnote" (modify). |
| get_recipientA | Get detailed information about a specific recipient by ID in LogicMonitor (LM) monitoring. Returns: Complete recipient details: type, name, contact information (email/phone/URL), notification method, timezone, schedule restrictions, rate limiting settings. When to use:
Details returned:
Workflow: Use "list_recipients" to find recipientId, then use this tool for complete configuration. Related tools: "list_recipients" (find recipient), "update_recipient" (modify), "list_escalation_chains" (usage). |
| get_recipient_groupA | Get detailed information about a specific recipient group by ID in LogicMonitor (LM) monitoring. Returns: Complete recipient group details: name, description, list of all members (recipients), member contact info, escalation chains using this group. When to use:
Key information returned:
Before modifying group: Review escalation chain usage to understand impact of changes. Removing member from group affects all chains using that group. Workflow: Use "list_recipient_groups" to find groupId, then use this tool to review membership before updating. Related tools: "list_recipient_groups" (find groups), "update_recipient_group" (modify), "list_escalation_chains" (see where used). |
| get_reportA | Get detailed information about a specific report by its ID in LogicMonitor (LM) monitoring. Returns: Complete report details: name, type, description, schedule (daily/weekly/monthly), recipients, format, data sources (which resources/devices/groups), date range, customization settings, last run timestamp, delivery status. When to use:
Configuration details:
Workflow: Use "list_reports" to find reportId, then use this tool for complete configuration. Related tools: "list_reports" (find reports), "update_report" (modify), "generate_report" (run now). |
| get_report_groupA | Get detailed information about a specific report group by ID in LogicMonitor (LM) monitoring. Returns: Complete report group details: name, full path, parentId, description, number of reports (direct and total), number of subgroups. When to use:
Workflow: Use "list_report_groups" to find groupId, then use this tool for complete details. Related tools: "list_report_groups" (find groups), "list_reports" (reports in group), "create_report_group" (create new). |
| get_resourceA | Get detailed information about a specific resource/device in LogicMonitor (LM) monitoring by its ID. Returns: Complete resource/device details including: displayName, IP/hostname, hostStatus, alertStatus, collector assignment, resource/device type, custom properties, applied datasources, group memberships, last data time, creation date. When to use:
Workflow: Use "list_resources" or "search_resources" first to find the deviceId, then use this tool for complete details. Related tools: "list_resource_datasources" (see what's monitored), "list_resource_properties" (view all properties), "generate_resource_link" (get UI link). |
| get_resource_datasourceA | Get detailed information about a specific datasource applied to a resource/device in LogicMonitor (LM) monitoring. Returns: Complete resource/device datasource details: dataSourceName, status, alert status, number of instances, monitoring configuration, stop monitoring flag, custom properties, graphs. When to use:
Key fields:
Workflow: Use "list_device_datasources" to find deviceDataSourceId, then use this tool for detailed status. Related tools: "list_device_datasources" (find datasource), "list_device_instances" (get instances), "update_device_datasource" (enable/disable). |
| get_resource_groupA | Get detailed information about a specific resource/device group by its ID in LogicMonitor (LM) monitoring. Returns: Complete group details: name, full path, parentId, description, custom properties, number of resource/device (direct and total), number of subgroups, alert status, SDT status. When to use:
Key information:
Custom properties inheritance: Properties set on group are inherited by ALL resource/device in group. Common uses:
Workflow: Use "list_resource_groups" to find groupId, then use this tool for complete details including inherited properties. Related tools: "list_resource_groups" (find groups), "create_resource_group" (create new), "list_resources" (devices in group). |
| get_resource_instance_dataA | Get time-series metrics/datapoints data (e.g., CPU/memory/network utilization) for a specific resource/device datasource instance in LogicMonitor (LM) monitoring. Returns: Time-series data with timestamps and values for requested datapoints. Format: {timestamps: [epoch1, epoch2], values: {datapoint1: [val1, val2], datapoint2: [val1, val2]}}. When to use:
Required workflow (3 steps):
Parameters:
Example: Get last hour CPU data: start=Date.now()-3600000, end=Date.now() Time range tips: If omitted, returns last 2 hours. Max range: 1 year. Use shorter ranges for better performance. Related tools: "list_resource_datasources", "list_resource_instances". |
| get_roleA | Get detailed information about a specific role by its ID in LogicMonitor (LM) monitoring. Returns: Complete role details: name, description, custom flag, detailed permission matrix (view/manage/delete/acknowledge for each area: resources/devices, alerts, dashboards, reports, settings, users). When to use:
Permission granularity returned:
Use cases:
Workflow: Use "list_roles" to find roleId, then use this tool to review detailed permissions before assigning to users. Related tools: "list_roles" (find roles), "list_users" (see who has this role), "create_role" (create custom role). |
| get_sdtA | Get detailed information about a specific Scheduled Down Time (SDT) by its ID in LogicMonitor (LM) monitoring. Returns: Complete SDT details: type, device/group affected, start/end times, duration, comment, who created it, status (active/scheduled/expired), recurrence settings. When to use:
Status meanings:
Workflow: Use "list_sdts" to find SDT ID, then use this tool for complete details before deciding to extend or delete. Related tools: "list_sdts" (find SDTs), "create_resource_sdt" (create new), "delete_sdt" (cancel). |
| get_serviceA | Get detailed information about a specific service by ID in LogicMonitor (LM) monitoring. Returns: Complete service details: name, description, health status, dependency tree (all resources comprising service), SLA/SLO configuration, availability statistics, alert rules, service group. When to use:
Key information returned:
Troubleshooting workflow: Service shows "Down" → Check dependency tree → Identify which specific resource(s) failed → Address those resources → Service auto-recovers when dependencies healthy Workflow: Use "list_services" to find serviceId, then use this tool for complete dependency analysis. Related tools: "list_services" (find service), "update_service" (modify dependencies), "list_resources" (see health of dependent resources). |
| get_service_groupA | Get detailed information about a specific service group by ID in LogicMonitor (LM) monitoring. Returns: Complete service group details: name, full path, parentId, description, number of services (direct and total), number of subgroups. When to use:
Workflow: Use "list_service_groups" to find groupId, then use this tool for complete details. Related tools: "list_service_groups" (find groups), "list_services" (services in group), "create_service_group" (create new). |
| get_topologyA | Get network topology information in LogicMonitor (LM) monitoring. Returns: Network topology data with: resource/device relationships, network connections, parent-child hierarchies, Layer 2/Layer 3 connectivity maps. What is topology: Automatically discovered network relationship map showing how resource/device connect to each other. LogicMonitor uses SNMP, CDP (Cisco Discovery Protocol), LLDP (Link Layer Discovery Protocol), and other methods to build network topology maps. When to use:
Topology information includes:
Use cases:
How LogicMonitor discovers topology:
Related tools: "list_resources" (view resources/devices), "get_resource" (device details including connections). |
| get_userA | Get detailed information about a specific user by their ID in LogicMonitor (LM) monitoring. Returns: Complete user details: username, email, firstName, lastName, roles (permissions), status (active/suspended), last login time, created date, phone, timezone, API token count, two-factor auth status. When to use:
Key information:
Security audit use cases:
Workflow: Use "list_users" to find userId, then use this tool for complete user profile. Related tools: "list_users" (find user), "list_roles" (see available roles), "list_api_tokens" (view user's tokens), "update_user" (modify). |
| get_websiteA | Get detailed information about a specific website monitor by its ID in LogicMonitor (LM) monitoring. Returns: Complete website monitor details: name, type (webcheck/pingcheck), domain/URL, monitoring configuration, checkpoint locations, response time thresholds, SSL settings, authentication, custom headers, alert status. When to use:
Configuration details returned:
Use cases:
Workflow: Use "list_websites" to find websiteId, then use this tool for complete monitoring configuration. Related tools: "list_websites" (find website), "update_website" (modify), "generate_website_link" (get URL), "list_website_checkpoints" (available locations). |
| get_website_groupA | Get detailed information about a specific website group by its ID in LogicMonitor (LM) monitoring. Returns: Complete website group details: name, full path, parentId, description, number of websites (direct and total), number of subgroups, alert status. When to use:
Workflow: Use "list_website_groups" to find groupId, then use this tool for complete details. Related tools: "list_website_groups" (find groups), "list_websites" (websites in group), "create_website_group" (create new). |
| list_access_groupsA | List all access groups in LogicMonitor (LM) monitoring. Returns: Array of access groups with: id, name, description, tenant ID, number of associated resources, number of users. What are access groups: Permission boundaries that control WHICH resources users can see and manage. Used in multi-tenant environments to isolate customer data, or to segment access by team/department. Users assigned to access group can only see resources in that group. When to use:
Access groups vs Roles (important distinction):
Common use cases: MSP / Multi-tenant:
Departmental isolation:
Environment separation:
Workflow: Use this tool to find access groups, then assign users to groups via "update_user" to control resource visibility. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_access_group" (details), "create_access_group" (create new), "list_users" (see user assignments), "list_resources" (associate resource/device with groups). |
| list_alert_rulesA | List all alert rules in LogicMonitor (LM) monitoring. Returns: Array of alert rules with: id, name, priority, enabled status, matching conditions (device/datasource/severity filters), escalation chain assigned, suppression settings. What are alert rules: The ROUTING LOGIC that determines "which alerts go to which people." Act as traffic directors: "IF alert matches these conditions, THEN send to this escalation chain." Rules are evaluated in priority order (1st match wins). When to use:
How alert rules work: Alert triggers → Rules evaluated in priority order → First matching rule wins → Routes alert to that rule's escalation chain → Escalation chain notifies recipients Common alert rule patterns:
Use cases:
Critical for notification troubleshooting: If alerts aren't reaching people, check:
Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_alert_rule" (detailed conditions), "list_escalation_chains" (destination chains), "update_alert_rule" (modify routing). |
| list_alertsA | List active alerts in LogicMonitor (LM) monitoring. Returns: Array of alerts with: id (alertId), severity (critical/error/warning), resource name, datasource, datapoint, alert message, start time (startEpoch), acknowledgement status (acked), alert rule. When to use:
Two search modes:
Common filter patterns:
Query vs Filter:
Important: Alert API does NOT support OR operator (||). Use comma for AND only. For complex queries, make multiple calls. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_alert" (full details), "acknowledge_alert" (acknowledge), "add_alert_note" (add notes), "generate_alert_link" (get URL). |
| list_api_tokensA | List API tokens for a specific user in LogicMonitor (LM) monitoring. Returns: Array of API tokens for specified user with: id, note (description), created date, last used date, status (active/inactive), access ID, roles inherited from user. What are API tokens: Authentication credentials for LogicMonitor REST API. Alternative to username/password for programmatic access. Each token inherits permissions from its user. When to use:
Security considerations:
Common use cases:
Best practices:
Security workflow:
Workflow: Use this tool with userId from "list_users" to audit that user's API access. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "list_users" (find userId), "create_api_token" (generate new), "delete_api_token" (revoke access). |
| list_audit_logsA | List audit logs in LogicMonitor (LM) monitoring for compliance and security auditing. Returns: Array of audit log entries with: id, username, IP address, timestamp (happenedOn in epoch SECONDS), description of action performed, sessionId. When to use:
Two search modes:
Common filter patterns:
Query vs Filter:
Critical notes:
Web UI access: https://mycompany.logicmonitor.com/santaba/uiv4/settings/access-logs (Settings → Audit Logs) Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_audit_log" (details of specific entry). |
| list_collector_groupsA | List all collector groups (folders) in LogicMonitor (LM) monitoring. Returns: Array of collector groups with: id, name, parentId, full path, description, number of collectors, number of subgroups. What are collector groups: Organizational folders for collectors (monitoring agents), similar to resource/device groups. Used to categorize collectors by location, function, or customer. When to use:
Common organization patterns:
Use cases:
Workflow: Use this tool to browse hierarchy, then "list_collectors" filtered by groupId to see collectors in specific folder. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_collector_group" (details), "list_collectors" (collectors in group), "create_collector_group" (create folder). |
| list_collector_versionsA | List available collector versions in LogicMonitor (LM) monitoring. Returns: Array of collector versions with: version number, release date, stability level (GA/EA/RC), changelog summary, download size, platform support (Windows/Linux), mandatory/recommended flag. What are collector versions: Software releases for LogicMonitor collector agents. Collectors are installed on your infrastructure to gather monitoring data. Staying current ensures latest features, bug fixes, and security patches. When to use:
Version types:
Collector update workflow: 1. Use this tool to check available versions 2. Review changelog for breaking changes 3. Test new version on non-production collector first 4. Use "get_collector" to check current version on your collectors 5. Update collectors via LogicMonitor UI or API 6. Monitor collector health after upgrade Version numbering: Format is typically X.Y.Z (e.g., 34.100.0) where:
Best practices:
Common scenarios:
Related tools: "get_collector" (check current version on collector), "list_collectors" (find collectors to upgrade). |
| list_collectorsA | List all LogicMonitor (LM) monitoring collectors (monitoring agents). Returns: Array of collectors with: id, description (collector name), hostname, platform (Windows/Linux), status (alive/dead), build version, number of monitored resources/devices, last heartbeat time. When to use:
What are collectors: Lightweight agents installed on-premise or in cloud that collect metrics from resources/devices. Each resource/device must be assigned to one collector. Common filter patterns:
Before creating resources/devices: Use this tool to find collectorId for the "preferredCollectorId" parameter in "create_resource". Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_collector" (details), "list_collector_groups" (browse groups), "list_collector_versions" (check updates). |
| list_configsourcesA | List all ConfigSources in LogicMonitor (LM) monitoring. Returns: Array of ConfigSources with: id, name, displayName, description, appliesTo logic, collection method. What are ConfigSources: Track configuration file changes for compliance and change management. Similar to datasources, but for configs instead of metrics. Alert when configs change unexpectedly. When to use:
What configs can be tracked:
Use cases:
Common ConfigSources:
Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_configsource" (details), "list_device_configs" (see configs for device). |
| list_dashboard_groupsA | List all dashboard groups (folders) in LogicMonitor (LM) monitoring. Returns: Array of dashboard groups with: id, name, parentId, full path, description, number of dashboards, number of subgroups, owner. What are dashboard groups: Organizational folders for dashboards, like directories in a file system. Used to organize dashboards by team, function, or application. When to use:
Common organization patterns:
Workflow: Use this tool to browse hierarchy, then "list_dashboards" filtered by groupId to see dashboards in specific folder. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_dashboard_group" (details), "list_dashboards" (dashboards in group), "create_dashboard_group" (create folder). |
| list_dashboardsA | List all dashboards in LogicMonitor (LM) monitoring. Returns: Array of dashboards with: id, name, description, groupId, groupName, widget count, owner. When to use:
Common filter patterns:
Next step: Use "generate_dashboard_link" with the dashboard ID to get the full clickable URL for sharing. Tip: Dashboards are organized in groups. Use "list_dashboard_groups" to browse the hierarchy. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_dashboard" (details), "generate_dashboard_link" (get URL), "list_dashboard_groups" (browse hierarchy). |
| list_datasourcesA | List all available datasources in LogicMonitor (LM) monitoring. Returns: Array of datasources with: id, name, displayName, description, appliesTo (which resource/device it monitors), collection method, datapoints/metrics collected. What are datasources: Templates that define WHAT to monitor (e.g., CPU, memory, disk), HOW to collect it (SNMP, WMI, API), and WHEN to alert. LogicMonitor has 2000+ pre-built datasources for common technologies. When to use:
Common filter patterns:
Examples: AWS_EC2 (monitors EC2 instances), SNMP_Network_Interfaces (network stats), WinCPU (Windows CPU), Linux_SSH (Linux via SSH). Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_datasource" (details), "list_resource_datasources" (see what's applied to specific resource/device). |
| list_escalation_chainsA | List all escalation chains in LogicMonitor (LM) monitoring. Returns: Array of escalation chains with: id, name, description, escalation stages, recipients at each stage, timing/delays, enabled status. What are escalation chains: Define HOW and WHO gets notified when alerts trigger. Multi-stage notification workflows: Stage 1 (notify team lead immediately) → Stage 2 (if still open after 15 min, notify manager) → Stage 3 (if still open after 30 min, page director). When to use:
How escalation chains work: Alert triggers → Alert Rule matches → Routes to Escalation Chain → Stage 1 notifies immediately → Wait X minutes → If still alerting, Stage 2 notifies → Repeat through stages Common escalation patterns:
Use cases:
Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_escalation_chain" (detailed stages), "list_alert_rules" (see which rules use chain), "list_recipients" (available notification targets). |
| list_eventsourcesA | List all EventSources in LogicMonitor (LM) monitoring. Returns: Array of EventSources with: id, name, displayName, description, appliesTo logic, event collection method. What are EventSources: Collect and process event data (logs, Windows events, syslog, traps). Different from DataSources (metrics) and ConfigSources (configs). Used for log monitoring and event correlation. When to use:
Event types collected:
Common EventSources:
Use cases:
Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_eventsource" (details), "list_device_eventsources" (events for device). |
| list_integrationsA | List all third-party integrations configured in LogicMonitor (LM) monitoring. Returns: Array of integrations with: id, name, type (Slack/PagerDuty/ServiceNow/Jira/etc), status (active/inactive), configuration summary, authentication status. What are integrations: Connections to external platforms for alert notifications, ticket creation, chat messages, incident management. Extend LogicMonitor alerting beyond email/SMS. When to use:
Popular integrations: Incident Management:
Ticketing:
Collaboration:
Workflow & Automation:
Use cases:
Integration status:
Workflow: Use this tool to find integrations, then use in escalation chains or as webhook recipients for alert delivery. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_integration" (configuration details), "test_integration" (verify working), "list_escalation_chains" (see usage). |
| list_netscansA | List all network discovery scans (NetScans) in LogicMonitor (LM) monitoring. Returns: Array of netscans with: id, name, description, scan method (nmap/script/ICMP/SNMP), schedule, target networks (IP ranges/subnets), collector, last run time, resource/device discovered. What are netscans: Automated network discovery that finds resource/device on your network and adds them to monitoring. Instead of manually adding resource/device one-by-one, netscan automatically discovers and onboards resource/device based on IP ranges or subnets. When to use:
How netscans work: Scheduled job → Scan network range (e.g., 192.168.1.0/24) → Find live resource/device → Check if already monitored → If new, add to LogicMonitor → Apply resource/device properties and datasources → Begin monitoring NetScan methods:
Common use cases:
Example NetScan configurations:
Workflow: Use this tool to review netscans, then "get_netscan" for detailed configuration including filters and resource/device properties. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_netscan" (configuration details), "create_netscan" (set up auto-discovery), "run_netscan" (trigger manual scan). |
| list_opsnotesA | List all operational notes (OpsNotes) in LogicMonitor (LM) monitoring. Returns: Array of OpsNotes with: id, note text, timestamp (epoch), who created it, tags, scope (applies to which resources/devices/groups), related SDTs. What are OpsNotes: Timestamped operational annotations displayed on graphs and dashboards. Document changes, deployments, maintenance, incidents - anything that might affect metrics. Appear as vertical lines on metric graphs at the time they occurred. When to use:
Use cases and examples: Deployments:
Incidents:
Maintenance:
Benefits:
Common filter patterns:
Displayed on: Graphs, dashboards, resource/device pages - visible wherever metrics are shown. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_opsnote" (details), "create_opsnote" (add new), "create_device_sdt" (maintenance windows). |
| list_recipient_groupsA | List all recipient groups in LogicMonitor (LM) monitoring. Returns: Array of recipient groups with: id, name, description, member count, recipients list. What are recipient groups: Collections of recipients treated as a single notification target. Simplify escalation chains by notifying entire teams at once. Example: "Database Team" group contains 5 team members - notify group = notify all 5. When to use:
Benefits over individual recipients:
Common recipient groups:
Use cases:
Workflow: Use this tool to find groups, then use in escalation chains to notify multiple people at once. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_recipient_group" (details), "list_recipients" (individual members), "list_escalation_chains" (see usage). |
| list_recipientsA | List all alert recipients (individual notification targets) in LogicMonitor (LM) monitoring. Returns: Array of recipients with: id, type (email/SMS/webhook), contact information, method (email address, phone number, webhook URL), name, status. What are recipients: Individual notification endpoints used in escalation chains. Can be: email addresses, SMS/phone numbers, webhook URLs, or integration endpoints (Slack, PagerDuty, etc.). When to use:
Recipient types explained:
Common use cases:
Recipients vs Recipient Groups:
Workflow: Use this tool to find available recipients, then use in "create_escalation_chain" or "update_escalation_chain" to set up notifications. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_recipient" (details), "list_recipient_groups" (group management), "list_escalation_chains" (see who gets notified). |
| list_report_groupsA | List all report groups (folders) in LogicMonitor (LM) monitoring. Returns: Array of report groups with: id, name, parentId, full path, description, number of reports, number of subgroups. What are report groups: Organizational folders for reports, like directories for files. Used to categorize reports by audience, frequency, purpose, or department. When to use:
Common organization patterns:
Use cases:
Workflow: Use this tool to browse hierarchy, then "list_reports" filtered by groupId to see reports in specific folder. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_report_group" (details), "list_reports" (reports in group), "create_report_group" (create folder). |
| list_reportsA | List all reports (scheduled and on-demand) in LogicMonitor (LM) monitoring. Returns: Array of reports with: id, name, type (alert/availability/capacity/performance), description, schedule, recipients, format (PDF/HTML/CSV), last run time. What are reports: Scheduled or on-demand documents summarizing monitoring data. Generate PDFs, HTML, or CSV files with metrics, alerts, availability statistics, capacity planning data. Automatically email to stakeholders. When to use:
Report types:
Common use cases:
Report schedules:
Workflow: Use this tool to find reports, then "get_report" for details, or "generate_report" to run on-demand. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_report" (details), "list_report_groups" (organization), "generate_report" (run now). |
| list_resource_datasourcesA | List datasources applied to a specific resource/device in LogicMonitor (LM) monitoring. Returns: Array of datasources actively monitoring this resource/device with: id (deviceDataSourceId), dataSourceName, dataSourceDisplayName, status, alert status, instance count, last poll time. When to use:
What you discover:
This is step 1 for getting metrics: Complete workflow to retrieve metric data: 1. Use this tool → get deviceDataSourceId for datasource you want (e.g., WinCPU) 2. Use "list_device_instances" → get instanceId for specific instance 3. Use "get_device_instance_data" → get actual metric values Troubleshooting use cases:
Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "list_device_instances" (next step), "get_device_instance_data" (get metrics), "update_device_datasource" (enable/disable). |
| list_resource_group_propertiesA | List all custom properties for a specific resource/device group in LogicMonitor (LM) monitoring. Properties set at group level are inherited by all resource/device in the group. Returns: Array of properties with: name, value, type (custom vs system), and inheritance source. When to use:
What are group properties: Key-value pairs set at group level that ALL resource/device in the group inherit. Common uses: credentials (SSH/SNMP), environment tags, owner/team info, monitoring settings. Property inheritance:
Common group properties:
Use cases:
Workflow: Use "list_resource_groups" to find groupId, then use this tool to see properties, then "update_device_group_property" to modify. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "update_device_group_property" (modify property), "get_resource_group" (group details), "list_device_properties" (device-level properties). |
| list_resource_groupsA | List all resource/device groups (folders) in LogicMonitor (LM) monitoring. Returns: Array of groups with: id, name, parentId, full path, description, number of resources/devices, number of subgroups, custom properties. What are groups: Organizational folders for resources/devices, like directories in a file system. Used to organize by location, environment, customer, or any logical structure. When to use:
Common use cases:
Common filter patterns:
Groups inherit properties: Custom properties set on group are inherited by all resource/device in that group (useful for credentials, location tags). Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_resource_group" (details), "create_resource_group" (create new), "list_resource_group_properties" (group properties). |
| list_resource_instancesA | List instances of a datasource on a specific resource/device in LogicMonitor (LM) monitoring. Returns: Array of instances with: id, name, displayName, description, status, alert status, last collection time. What are instances: Individual components monitored by a datasource. Examples: individual disks (C:, D:, E:), network interfaces (eth0, eth1), database tables, processes. When to use:
Example workflow: Device "web-server-01" has datasource "WinVolumeUsage-" → instances: C:, D:, E: (each disk is an instance) Device "router-01" has datasource "SNMP_Network_Interfaces" → instances: GigabitEthernet0/1, GigabitEthernet0/2 (each interface is an instance) Complete workflow to get metrics:
Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "list_resource_datasources" (first step), "get_resource_instance_data" (get metrics). |
| list_resource_propertiesA | List all custom properties (system and user-defined) for a specific resource/device in LogicMonitor (LM) monitoring. Returns: Array of properties with: name, value, source (device-level vs inherited from group), type (system vs custom). When to use:
Property types: System properties (auto-populated by LogicMonitor):
Custom properties (user-defined):
Property inheritance: Properties can be set at: Device level (highest priority) → Group level → Parent group (inherited). Datasource appliesTo logic uses properties: Many datasources check properties to decide if they should monitor device. Example: AWS_EC2 datasource checks if resource/device has "aws.resourcetype=ec2" property. Workflow: Use "list_resources" to find deviceId, then use this tool to see all properties including inherited ones. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "update_device_property" (modify), "get_resource" (see summary), "list_datasources" (see how properties affect monitoring). |
| list_resourcesA | List all monitored resources/devices in LogicMonitor (LM) monitoring. Returns: Array of resource/device with: id, displayName, name (IP/hostname), hostStatus (dead/alive/unknown), preferredCollectorId, deviceType, custom properties, group memberships. When to use:
Two search modes:
Common filter patterns:
Query vs Filter:
Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Performance tips: Use autoPaginate:false for large environments (>1000 resources/devices) and paginate manually to avoid timeouts. Related tools: "get_resource" (details), "generate_resource_link" (get UI link). |
| list_rolesA | List all roles (permission sets) in LogicMonitor (LM) monitoring. Returns: Array of roles with: id, name, description, custom flag, associated users count, permissions (view/manage/delete for resources/alerts/reports/settings). What are roles: Permission templates assigned to users. Control who can view/modify/delete resources, alerts, dashboards, settings. Essential for RBAC (role-based access control). When to use:
Built-in roles (examples):
Custom roles: Organizations create custom roles for specific needs (e.g., "database-team-role", "view-prod-only"). Common use cases:
Workflow: Use this tool to discover roles, then "get_role" for detailed permissions, then use in "create_user" or "update_user". Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_role" (detailed permissions), "list_users" (see user assignments), "create_user" (assign roles to new users). |
| list_sdtsA | List all Scheduled Down Times (SDTs) in LogicMonitor (LM) monitoring. Returns: Array of SDTs with: id, type (DeviceSDT/DeviceGroupSDT/etc), device/group name, start/end times, duration, comment, creator, status (active/scheduled/expired). What are SDTs: Maintenance windows that suppress alerting to prevent false alarms during planned work. No alerts are generated during SDT periods. When to use:
Common filter patterns:
SDT types explained:
Best practice: Always add meaningful comment explaining maintenance reason for audit trail. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "create_resource_sdt" (schedule maintenance), "delete_sdt" (cancel maintenance), "get_sdt" (details). |
| list_service_groupsA | List all service groups (folders) in LogicMonitor (LM) monitoring. Returns: Array of service groups with: id, name, parentId, full path, description, number of services, number of subgroups. What are service groups: Organizational folders for business services, similar to resource/device groups for resources/devices. Used to categorize services by business unit, region, customer, or application stack. When to use:
Common organization patterns:
Use cases:
Workflow: Use this tool to browse hierarchy, then "list_services" filtered by groupId to see services in specific folder. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_service_group" (details), "list_services" (services in group), "create_service_group" (create folder). |
| list_servicesA | List all business services in LogicMonitor (LM) monitoring. Returns: Array of services with: id, name, description, health status, dependencies, monitored resources, service level objectives (SLOs), availability percentage. What are services: Business-level monitoring constructs that aggregate multiple resources/devices/resources into a single health status. Represent customer-facing services, applications, or business processes. Example: "E-Commerce Platform" service includes web servers, databases, load balancers, and APIs - one health indicator for entire platform. When to use:
Service health calculation: Service health = Aggregate of all dependent resources. If critical resource fails, service status = down. Allows stakeholders to see "Is the application working?" instead of "Is server X working?" Use cases and examples: Customer-facing services:
Internal services:
Benefits:
Common filter patterns:
Workflow: Use this tool to find services, then "get_service" for detailed dependency tree and health status. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_service" (details and dependencies), "list_service_groups" (organization), "create_service" (define new business service). |
| list_usersA | List all users in LogicMonitor (LM) monitoring. Returns: Array of users with: id, username, email, roles, status (active/suspended), last login time, created date, API token count. When to use:
Common filter patterns:
Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_user" (details), "list_roles" (available roles), "list_api_tokens" (user's API tokens). |
| list_website_checkpointsA | List available checkpoint locations for website monitoring in LogicMonitor (LM) monitoring. Returns: Array of checkpoint locations with: id, name, geographic region, status, type (internal/external). What are checkpoints: Global testing locations from which LogicMonitor runs synthetic website checks. Think "test my website from New York, London, Tokyo" - checkpoints are those global vantage points. When to use:
Checkpoint types:
Common checkpoint locations:
Use cases:
Best practices:
Workflow: Use this tool to discover available locations, then use those checkpoint IDs when creating website monitors via "create_website". Related tools: "list_websites" (existing monitors), "create_website" (configure checkpoints), "get_website" (verify checkpoint configuration). |
| list_website_groupsA | List all website groups (folders) in LogicMonitor (LM) monitoring. Returns: Array of website groups with: id, name, parentId, full path, description, number of websites, number of subgroups. What are website groups: Organizational folders for website monitors (synthetic checks), similar to resource/device groups. Used to categorize monitored URLs/services by application, environment, or customer. When to use:
Common organization patterns:
Use cases:
Workflow: Use this tool to browse hierarchy, then "list_websites" filtered by groupId to see monitors in specific folder. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_website_group" (details), "list_websites" (websites in group), "create_website_group" (create folder). |
| list_websitesA | List all website monitors (synthetic checks) in LogicMonitor (LM) monitoring. Returns: Array of website monitors with: id, name, type (webcheck/pingcheck), domain/URL, status, checkpoint locations, response time, availability percentage. What are website monitors: Synthetic checks that test URL/service availability from multiple global locations. Like "ping from the internet" to verify your services are accessible. When to use:
Monitor types:
Common filter patterns:
Use cases: Monitor public websites, API endpoints, login pages, load balancer health checks, SaaS service availability. Important: A negative "total" value in the response indicates incomplete results. Use pagination (size/offset parameters) or set autoPaginate: true to retrieve all items. Related tools: "get_website" (details), "create_website" (add new), "generate_website_link" (get URL). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| resource_check | Interactive resource check for a LogicMonitor resource/device. Searches for a resource by name or custom filter, allows selection if multiple matches, then displays comprehensive information including resource details, groups, collector assignment, and current metrics (CPU, memory, network, ping, etc.) in a formatted table for selected resource. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| LogicMonitor (LM) API Definition (Swagger/OpenAPI) | Complete LogicMonitor REST API v3 definition in Swagger/OpenAPI format. Contains all available endpoints, request/response schemas, authentication methods, and API documentation. Use this to understand the LogicMonitor API structure, available operations, and data models. Source: https://www.logicmonitor.com/swagger-ui-master/api-v3/dist/swagger.json Before making API calls, you should authenticate yourself. You can make v3 requests by including a '?v=3' query parameter or by including a 'X-Version:3' header. Properties passed in the body of an API call are case sensitive. When adding cloud devices, do not use NetScan to discover cloud devices as it can lead to issues. Instead, follow the new onboarding process. For more information, see LM Cloud Monitoring Overview, Enabling Cloud Monitoring using Local Collector, and AWS Monitoring Setup. Offset indicates the position of a specific record in the dataset. It is the starting point of the list. For example, there is an array of 10 elements and in the API request you specify offset as 4. The API response will return result from the 5th element onwards. For fetching alerts, the offset limit is 10000 alerts. Size indicates the number of elements to return at a time in the response. For example, if you specify size=60, then the response will return result in a batch of 60. LogicMonitor REST API v3 supports maximum size of 1000 records. Even if you specify a number above 1000, the response will always return 1000 records. Example, there are 7000 alerts and you set offset=1000 and size=500. In the response, the API will return alerts from 1001 to 1500. In case of SDTs endpoints, the response may contain extra fields depending upon the type of SDT that you select. In case of Widgets endpoints, based on the widget type you select, the request and response will contain additional attributes. For more details about the attributes, refer models specific to the selected widget type at the end of the Swagger documentation. |
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/monitoringartist/logicmonitor-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server