Skip to main content
Glama
Sign In
ESET-MCP

ESET-MCP

by maciekaz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

patch_patch_management__list_device_patching_details

Read-onlyIdempotent

List device patching details for ESET-managed devices, with optional filters for device, device group, and time period, to review patch status and history.

Instructions

List patching details - (GET /v1/patching-process-details) - History is pruned repeatedly to prevent database flooding. Entries from at least the previous 30 days should be available at any time.

Input Schema

NameRequiredDescriptionDefault
fieldsNoOptional server-side projection: return only these keys for each list-item in the response. Reduces token usage on large list endpoints. Example: ['uuid','displayName']. Top-level fields (e.g. nextPageToken) are always preserved. Not forwarded to ESET - applied locally after fetch.
pageSizeNoLimit for pagination purposes. If unspecified or 0, the default value is 50. The maximum value is 1000; values above 1000 will be coerced to 1000. > **Info:** > For more information, refer to [Paginating Requests in APIs](https://medium.com/@ignaciochiazzo/paginating-requests-in-apis-d4883d4c1c4c) > > or [Design Patterns: Pagination](https://google.aip.dev/158)
pageTokenNoPage token of the current page. If not given or "", the first page is returned. > **Info:** > For more information, refer to [Paginating Requests in APIs](https://medium.com/@ignaciochiazzo/paginating-requests-in-apis-d4883d4c1c4c) > > or [Design Patterns: Pagination](https://google.aip.dev/158)
deviceUuidNoReference to the device whose patching details should be listed. If empty or null, patching details of all devices accessible to the caller will be included in the response. type: device_management.v1.Device
deviceGroupUuidNoReference to the [device group]. If filled, only the patching details of devices within the group will be included in the response. If empty or null, scan details of any device accessible to the caller will be included in the response. type: device_management.v1.DeviceGroup
timePeriod.endTimeNoOptional. Exclusive end of the interval. If specified, a Timestamp matching this interval will have to be before the end.
timePeriod.startTimeNoOptional. Inclusive start of the interval. If specified, a Timestamp matching this interval will have to be the same or after the start.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds a genuinely useful non-annotated trait: history is pruned, so only ~30 days of entries are available. It says nothing about pagination defaults (schema says 50/1000) or result ordering, so the disclosure is partial.

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?

Two short sentences, front-loaded with the action, with no filler. The embedded endpoint path is minor redundancy given the annotation title already carries it, but it costs little.

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

Completeness3/5

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

For a 7-parameter, zero-required list tool with no output schema, the definition covers the retention caveat but not the shape of a patching-detail record, the effect of combining deviceUuid with deviceGroupUuid, or how it differs from the recent-application variant. Just adequate against the rich schema.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (fields projection, pageSize/pageToken, deviceUuid, deviceGroupUuid, timePeriod bounds) is already fully documented. The description adds no scoping or format detail beyond the schema, so the baseline of 3 applies.

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

Purpose4/5

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

The description states a clear verb+resource ('List patching details') and even names the backing endpoint (GET /v1/patching-process-details). It does not differentiate from siblings such as patch_patch_management__list_recent_application_patching_details or patch_unpatched_devices__list_device_patches, leaving the agent to infer that this is the device-level, full-history variant.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is given, and no alternative tool is named. The only usage-adjacent information is the retention note about 30 days of history, which does not tell the agent which sibling to pick for recent vs. historical or application-level patching data.

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