Get detailed information for a specific LogicMonitor device group by supplying its group ID, including appliesTo expression and parent ID.
Get detailed information about a specific device/resource group, including appliesTo expression and parent ID
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Device group ID |
Changes observed during successful MCP inspections.
v4.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds that the tool returns 'appliesTo expression and parent ID', which is return-content information rather than behavioral traits. It does not contradict annotations. The additional detail is useful but not substantial beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and includes the key detail about what information is returned. There is no filler or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should provide a more complete picture of what is returned. It mentions 'detailed information' and two specific fields, but does not enumerate all possible return fields. Given the tool's simplicity and annotations, this is adequate but leaves some ambiguity about the full response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the only parameter group_id described as 'Device group ID'. The description does not add further meaning, format, or constraints beyond the schema. With full coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'specific device/resource group', and specifies that it includes 'appliesTo expression and parent ID'. This distinguishes it from the plural sibling get_device_groups, which likely lists groups, and from other get_* tools targeting different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives like get_device_groups. However, the singular 'specific' implies usage for a single group by ID, and the presence of the plural sibling suggests the distinction, but it is only implied, not stated. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.