Skip to main content
Glama
Sign In
ESET-MCP

ESET-MCP

by maciekaz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

incident_incidents__list_incidents

Read-onlyIdempotent

Lists ESET incidents with filter, ordering, and pagination to retrieve and review security incident data.

Instructions

List incidents - (GET /v2/incidents) - Returns a list of incidents matching the filter. The list is ordered according to order_by.

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.
filterNoA filter string compliant with [Filtering](https://google.aip.dev/160). Field names must be expressed in lower_case_with_underscores form or in lowerCamelCase form, for example, display_name or displayName. For time filtering, use the timestamp offset representation. Examples: - incident.create_time >= timestamp("2024-10-01T12:41:39+00:00") - incident.assignee_uuid == "uuid" - incident.displayName.contains("abc") - displayName.contains("abc") > **Info:** > For more details about filtering, see [ESET Connect Online Help](https://help.eset.com/eset_connect/en-US/incident_management_v2_incidents_get.html#s-filtering) > Common Expression Language is defined at [GitHub: Google Open Source](https://github.com/google/cel-spec/blob/master/doc/intro.md) along with libraries for [C++/C#](https://github.com/google/cel-go), [Go](https://github.com/google/cel-go)
orderByNoIt is a comma-separated list of fields. The default sorting order is ascending. To specify the descending order for a field, users must append a " desc" suffix. All actual fields and subfields from the object [Incident] can be used. Subfields are specified with a . character. Field names must be expressed in lower_case_with_underscores form, for example, display_name. > **Info:** > Modeled after: [Standard Methods: List Ordering](https://google.aip.dev/132#ordering) > For more details about ordering, see [ESET Connect Online Help](https://help.eset.com/eset_connect/en-US/incident_management_v2_incidents_get.html#s-ordering) For example, the result will be ordered by the device name given by the user and by the incident severity in the reverse order: display_name, severity desc
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)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds little beyond stating that filtering and ordering apply, repeating behavior already documented in the parameter schemas; it says nothing about pagination defaults, auth, or result shape.

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 core action and returning constraint. Minor waste in the redundant endpoint notation, and the `order_by` vs `orderBy` naming mismatch is a small inconsistency, but it is tight overall.

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 five-parameter list endpoint with no output schema and rich annotations, the description is adequate but incomplete: it does not describe what an incident list item contains or when to page versus fetch a full incident via siblings. It covers the essentials an agent needs to call it, relying on the schema for parameter detail.

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 all five parameters are fully documented in the schema. The description names `filter` and `order_by` but adds no semantics beyond what those schema entries already provide, so the baseline 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 gives a specific verb+resource ('List incidents') and states it returns incidents matching `filter`, ordered by `order_by`. It clearly identifies what the tool does, but offers no differentiation from siblings like incident_incidents__get_incident or incident_full_context.

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?

There is no explicit when-to-use guidance, no mention of when not to use it, and no reference to the sibling get_incident tool for fetching a single record. Usage is only implied by the name and the mention of filter/order_by.

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