Skip to main content
Glama
AIops-tools

endpoint-aiops-mcp

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

patch_compliance

Evaluate patch-compliance SLA by calculating the percentage of endpoints on the target patch level, comparing it to the required threshold, and listing non-compliant endpoints.

Instructions

[READ] Patch-compliance SLA measure: % of the fleet on the target patch level.

Reframes patch_status (the patch-level distribution) as an SLA/compliance verdict: what fraction of the fleet is on the target level, whether that meets the SLA, and which endpoints are non-compliant. Compliance is an exact string match on patchLevel — a transparent check, not a version-semantics parser. Injected-only: pass 'endpoints' (inventory rows); no live collection.

Args: endpoints: Injected inventory rows to evaluate (e.g. from endpoint_list). target_patch: Desired patch level; omit to use the fleet-majority level. sla_pct: Compliance SLA threshold percent; default 95.0. limit: Max non-compliant endpoints to return (default 200).

Returns dict: {endpointsEvaluated, targetPatch, targetSource, slaTargetPct, complianceRatePct, compliantCount, verdict, nonCompliantCount, nonCompliant:{items[], returned, limit, truncated}, note}. The rate is always computed over the whole fleet, never over the capped list.

Example: patch_compliance(endpoints=[{"hostname":"tc01","patchLevel":"2026-06"}, {"hostname":"tc02","patchLevel":"2026-05"}], target_patch="2026-06").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
sla_pctNo
endpointsYes
target_patchNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.10.3
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 200,
+  "title": "Limit",
+  "type": "integer"
+}
  2. Addedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of disclosure. It clearly labels the tool as '[READ]' (read-only), states 'no live collection' (no side effects), and reveals the internal check is 'an exact string match on patchLevel — a transparent check, not a version-semantics parser.' It also discloses the important nuance that 'the rate is always computed over the whole fleet, never over the capped list,' which prevents misinterpretation of the limited output.

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 structured with a clear opening summary, then separate Args, Returns, and Example sections. It is somewhat verbose but every sentence contributes critical information, such as the fleet-wide rate computation caveat. The front-loading of the purpose and the injection constraint ensures an agent quickly understands the tool's role.

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?

For a computation tool with 4 parameters and no output schema, the description is remarkably complete. It details the return dictionary keys, explains the default target_patch behavior, specifies the compliance rule (exact string match), and clarifies the non-compliance listing truncation. Combined with the clear injection requirement and example, an agent has everything needed to call it correctly.

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 description coverage is 0%, so the description must fully explain each parameter. It does: 'endpoints: Injected inventory rows to evaluate (e.g. from endpoint_list)', 'target_patch: Desired patch level; omit to use the fleet-majority level', 'sla_pct: Compliance SLA threshold percent; default 95.0', and 'limit: Max non-compliant endpoints to return (default 200)'. This fully compensates for the schema gap, even providing a concrete example.

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 opens with a clear verb and resource: 'Patch-compliance SLA measure: % of the fleet on the target patch level.' It explicitly distinguishes itself from the sibling patch_status by stating it 'Reframes patch_status (the patch-level distribution) as an SLA/compliance verdict,' making its unique role unambiguous.

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

Usage Guidelines4/5

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

It explains when to use this tool by noting it is 'Injected-only' and expects 'endpoints' from inventory (e.g., endpoint_list), and frames its relationship to patch_status as a reframing into SLA terms. While it does not explicitly list when NOT to use it or name alternatives like drift_report, the injected-data constraint and the SLA focus provide clear usage context.

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

Deploy Server

Other Tools