Skip to main content
Glama
monitoringartist

LogicMonitor MCP Server

list_services

Read-only

Retrieve all business services with health status and dependencies to monitor application availability and track SLA compliance.

Instructions

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:

  • Monitor business service health vs individual resource/device health

  • Track SLA compliance for customer-facing services

  • Understand service dependencies

  • Create business-level dashboards

  • Report on application availability

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:

  • "E-Commerce Website" - Web servers + database + payment gateway + CDN

  • "Mobile App Backend" - API servers + auth service + push notifications

  • "SaaS Platform" - All infrastructure for multi-tenant application

Internal services:

  • "Employee VPN" - VPN servers + RADIUS auth + firewall

  • "Corporate Email" - Mail servers + spam filter + archiving

  • "CI/CD Pipeline" - Jenkins + artifact storage + deployment agents

Benefits:

  • Business perspective: Non-technical stakeholders understand "Shopping Cart is 99.5% available"

  • SLA tracking: Measure uptime for customer SLAs

  • Root cause: When service is down, see which specific resource failed

  • Dependencies: Visualize what resources comprise a service

Common filter patterns:

  • By status: filter:"status:normal" or filter:"status:dead"

  • By name: filter:"name~production"

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoNumber of results per page (default: 50, max: 1000).
offsetNoStarting offset for pagination (default: 0). Use this to skip a specific number of results.
autoPaginateNoAutomatically fetch all pages (default: false). When true, fetches all results across multiple pages. When false, returns only the requested page. Use false for large result sets to avoid long response times.
filterNoFilter expression using LogicMonitor query syntax. Examples: name:*prod*, displayName~*server*, id>100, hostStatus:normal. Available operators: : (equals), ~ (includes), !: (not equals), !~ (not includes), >: (greater than or equals), <: (less than or equals), > (greater than), < (less than). Multiple conditions: Use comma (,) for AND, use || for OR. Do NOT use &&.
fieldsNoComma-separated list of fields to include in response. Examples: "id,displayName,hostStatus" or use "*" for all fields. Omit this parameter to receive a curated set of commonly used fields.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral context beyond the readOnlyHint annotation, including details about return fields (with examples), the meaning of negative 'total' for pagination, and health calculation. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections and front-loaded key information, but it is lengthy. While rich, it could be more concise without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description thoroughly explains the return format, concepts, use cases, and workflow, making it complete for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value with filter pattern examples, explanation of autoPaginate behavior, and the negative total note, justifying a higher score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all business services in LogicMonitor, explains what services are, and distinguishes from sibling tools like 'get_service' and 'list_service_groups'. It uses specific verbs and context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'When to use' bullet points, common filter patterns, a workflow, and lists related tools, offering clear guidance on when to use this tool vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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