Skip to main content
Glama
monitoringartist

LogicMonitor MCP Server

by monitoringartist
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

get_resource_datasource

Read-only

Retrieve detailed information about a datasource applied to a device in LogicMonitor, including collection status, alert status, and instance count. Use this to troubleshoot data collection or verify monitoring configuration.

Instructions

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:

  • Check if datasource is collecting data

  • Review alert status for specific datasource

  • Verify custom thresholds

  • Get deviceDataSourceId for instance operations

  • Troubleshoot data collection issues

Key fields:

  • instanceNumber: How many instances (e.g., 4 network interfaces)

  • status: Collection status (normal vs error)

  • alertStatus: Any active alerts from this datasource

  • stopMonitoring: Whether datasource is disabled on this resource/device

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deviceIdYesThe resource/device ID
deviceDataSourceIdYesThe resource/device datasource ID
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.

Tool Definition Quality

A5/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true; description adds valuable behavioral context by listing key return fields (instanceNumber, status, alertStatus) and confirming it returns 'complete details'. No contradictions.

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?

Well-structured with sections: purpose, returns, when to use, key fields, workflow, related tools. Each sentence is valuable; no fluff. Front-loaded with main purpose.

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?

Despite no output schema, the description compensates by listing return fields and explaining use cases. It covers prerequisites (use list to get ID), and provides enough detail for an agent to decide if this tool is appropriate.

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

Parameters5/5

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

Schema has 100% coverage, but description adds context: explains 'fields' parameter with examples, and interprets key fields like 'instanceNumber' and 'status' in plain language. This helps agents understand parameter usage and return value semantics.

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 retrieves detailed information about a datasource applied to a resource. It uses specific verb 'Get' and resource 'datasource details', and distinguishes from siblings like 'list_resource_datasources' and 'get_datasource' via related tools section.

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?

Explicit 'When to use:' section lists concrete scenarios (check collection, review alert status, etc.). Also provides a workflow suggestion using 'list_device_datasources' first, and lists related tools for alternative actions.

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