Skip to main content
Glama
WYRE-AI

superops-mcp

by WYRE-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

superops_assets_patches

Retrieve patch status and details for a specific asset, including KB numbers, severity, approval, and installation status. Filter by severity or installation state.

Instructions

Get patch status and patch details for a specific asset: title, KB numbers, category, severity, approval status and installation status. installationStatus and severity may be combined; they are joined with AND. For a one-word roll-up of the asset's overall patch health instead of the per-patch list, use superops_custom_query with getAssetPatchStatus.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, 1-based (default: 1, max: 2147483647)
assetIdYesThe unique asset ID
pageSizeNoResults per page (default: 50, max: 100)
severityNoFilter by one or more patch severities, each matched whole and case-insensitively. Observed values are "Others" and "Recommended"; SuperOps validates them at runtime, so other severities may exist.
installationStatusNoFilter by patch installation status, matched whole and case-insensitively. Observed values are "Installed" and "NewOrMissing" — note this is the install state, not the separate `approvalStatus` (Approved/Pending).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.0.2
    • addedInput schema / properties / installationStatus
      Added value: +{
+  "description": "Filter by patch installation status, matched whole and case-insensitively. Observed values are \"Installed\" and \"NewOrMissing\" — note this is the install state, not the separate `approvalStatus` (Approved/Pending).",
+  "type": "string"
+}
    • addedInput schema / properties / page
      Added value: +{
+  "default": 1,
+  "description": "Page number, 1-based (default: 1, max: 2147483647)",
+  "type": "number"
+}
    • addedInput schema / properties / pageSize
      Added value: +{
+  "default": 50,
+  "description": "Results per page (default: 50, max: 100)",
+  "type": "number"
+}
    • changedInput schema / properties / severity / description
      Previous value: -"Filter by severity levels: Critical, Important, Moderate, Low"New value: +"Filter by one or more patch severities, each matched whole and case-insensitively. Observed values are \"Others\" and \"Recommended\"; SuperOps validates them at runtime, so other severities may exist."
    • removedInput schema / properties / status
      Removed value: -{
-  "description": "Filter patches by status: Pending, Installed, or Failed",
-  "enum": [
-    "Pending",
-    "Installed",
-    "Failed"
-  ],
-  "type": "string"
-}
  2. Addedv1.6.3
  3. Removedv1.6.0
  4. First observedv1.2.5

TDQS

A4.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that installationStatus and severity are joined with AND, but says nothing about pagination behavior, permissions, or result ordering despite a page/pageSize interface.

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?

Three sentences, front-loaded with the core purpose, followed by filter-combination semantics and then the alternative routing. No filler and every sentence carries information.

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

Completeness4/5

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

For a read-only listing with no output schema and no annotations, the description is largely complete: it lists returned fields and names the alternative tool. It stops short of describing pagination or result limits, which is the only notable gap.

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 the baseline is 3, but the description earns extra credit by explaining non-obvious semantics the schema does not express: how installationStatus and severity combine, and the distinct grouping of approval status versus install state.

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?

States a specific verb (Get) and resource (patch status and patch details for a specific asset) and enumerates the exact returned fields (title, KB numbers, category, severity, approval status, installation status). It also names the sibling alternative (superops_custom_query with getAssetPatchStatus), so an agent can distinguish it without opening either schema.

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?

Explicitly routes the agent: use this for the per-patch list, and use superops_custom_query with getAssetPatchStatus for a one-word roll-up of overall health. The condition that selects the alternative is stated, not left to inference, and the AND combination of filters is clarified.

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