Skip to main content
Glama
Sign In
F6 XDR MCP Server

F6 XDR MCP Server

Official
by F6-Security
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

xdr_count

Read-only

Count records in an XDR section, optionally filtered by query, to measure matching alerts, incidents, assets, or other data.

Instructions

Get the total count of records in an XDR section. Optionally filter by query to count matching records only. For application_versions this counts per-asset records, not distinct version strings.

Input Schema

NameRequiredDescriptionDefault
queryNoSearch query string using field:value syntax, e.g. 'resolved : "false" AND severity : "critical"'. Pass an empty string to list the whole section unfiltered — deliberately, since that can be a very large number of records. Fields can be combined with AND, OR, AND NOT, OR NOT and grouped with parentheses. A string value may contain * as a wildcard, in any position: name : "VDI-5*", file_name : "*.exe", domain : "*corp*". Without a wildcard a string value must match exactly. Numeric and date fields do not take wildcards. Call xdr_get_mapping for the fields a section accepts, xdr_get_filters for the values an enumerated field takes, and xdr_get_suggestions to look up the exact spelling of a value — a value outside the accepted set returns zero results rather than an error. Time filtering uses fields from xdr_get_mapping, typically timestamp, with relative (timestamp >= now-1d, now-6h) or absolute values (timestamp >= "2024-01-01T00:00:00.000+03:00"). The calendar-rounding forms now/d, now/w and now/M return nothing, so use now-1d and the like. Note that timestamp is a search field: the ordering parameter takes an entirely different set of names. For the "applications" section, filter by asset, e.g. (asset: "<machine_id>"). The "application_versions" section returns per-asset software version records. Filter by software_id: "<uuid from applications>" (supported even though absent from mapping), version: "1.2.3", or asset: "<machine_id or exact current_name>" identifying a single asset. For dates in this section use first_seen or last_seen, e.g. last_seen >= now-7d; ordering uses version, ts_created or ts_updated. A query the API cannot parse is not rejected — it is treated as free text, so verify that the results match what you asked for. (optional)
sectionYesSection name, one of: alerts, incidents, emails, files, events, connections, assets, modules, audit, applications, application_versions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.3.0
    • changedInput schema / properties / query / description
      Previous value: -"Search query string using field:value syntax, e.g. 'resolved : \"false\" AND severity : \"critical\"'. Pass an empty string to list the whole section unfiltered — deliberately, since that can be a very large number of records. Fields can be combined with AND, OR, AND NOT, OR NOT and grouped with parentheses. Call xdr_get_mapping for the fields a section accepts, and xdr_get_filters for the values an enumerated field takes — a value outside that set returns zero results rather than an error. Time filtering uses the timestamp field, relative (timestamp >= now-1d, now-6h) or absolute (timestamp >= \"2024-01-01T00:00:00.000+03:00\"). The calendar-rounding forms now/d, now/w and now/M return nothing, so use now-1d and the like. Note that timestamp is a search field: the ordering parameter takes an entirely different set of names. For the \"applications\" section, filter by asset, e.g. (asset: \"<machine_id>\"). A query the API cannot parse is not rejected — it is treated as free text, so verify that the results match what you asked for. (optional)"New value: +"Search query string using field:value syntax, e.g. 'resolved : \"false\" AND severity : \"critical\"'. Pass an empty string to list the whole section unfiltered — deliberately, since that can be a very large number of records. Fields can be combined with AND, OR, AND NOT, OR NOT and grouped with parentheses. A string value may contain * as a wildcard, in any position: name : \"VDI-5*\", file_name : \"*.exe\", domain : \"*corp*\". Without a wildcard a string value must match exactly. Numeric and date fields do not take wildcards. Call xdr_get_mapping for the fields a section accepts, xdr_get_filters for the values an enumerated field takes, and xdr_get_suggestions to look up the exact spelling of a value — a value outside the accepted set returns zero results rather than an error. Time filtering uses fields from xdr_get_mapping, typically timestamp, with relative (timestamp >= now-1d, now-6h) or absolute values (timestamp >= \"2024-01-01T00:00:00.000+03:00\"). The calendar-rounding forms now/d, now/w and now/M return nothing, so use now-1d and the like. Note that timestamp is a search field: the ordering parameter takes an entirely different set of names. For the \"applications\" section, filter by asset, e.g. (asset: \"<machine_id>\"). The \"application_versions\" section returns per-asset software version records. Filter by software_id: \"<uuid from applications>\" (supported even though absent from mapping), version: \"1.2.3\", or asset: \"<machine_id or exact current_name>\" identifying a single asset. For dates in this section use first_seen or last_seen, e.g. last_seen >= now-7d; ordering uses version, ts_created or ts_updated. A query the API cannot parse is not rejected — it is treated as free text, so verify that the results match what you asked for. (optional)"
    • changedInput schema / properties / section / description
      Previous value: -"Section name, one of: alerts, incidents, emails, files, events, connections, assets, modules, audit, applications"New value: +"Section name, one of: alerts, incidents, emails, files, events, connections, assets, modules, audit, applications, application_versions"
    • changedInput schema / properties / section / enum
      Previous value: -[
-  "alerts",
-  "incidents",
-  "emails",
-  "files",
-  "events",
-  "connections",
-  "assets",
-  "modules",
-  "audit",
-  "applications"
-]New value: +[
+  "alerts",
+  "incidents",
+  "emails",
+  "files",
+  "events",
+  "connections",
+  "assets",
+  "modules",
+  "audit",
+  "applications",
+  "application_versions"
+]
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a genuinely useful semantic caveat that application_versions counts per-asset records rather than distinct version strings, preventing a real misinterpretation of the returned number, though it says nothing about cost or performance on large sections.

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 short sentences, front-loaded with the core action, then the filtering option, then the one non-obvious caveat. No wasted wording and nothing buried.

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 two-parameter read tool with no output schema, the description is nearly complete; the schema carries all query syntax detail. The only mild gap is that it does not state the shape of the returned count (bare number vs object), though 'total count' strongly implies a scalar.

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%, and the query parameter is documented in exceptional depth in the schema itself. The description only restates that query optionally filters the count and adds the application_versions counting caveat, 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 specific verb and resource — get the total count of records in an XDR section — and clarifies the scope of the optional query filter. It distinguishes the count intent from the listing/search siblings implicitly rather than by naming xdr_search, so it is clear but lacks explicit sibling differentiation.

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

Usage Guidelines3/5

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

It implies when to use it (to obtain a total rather than records) and notes that the query can be omitted to count the whole section. It does not state when to prefer this over xdr_search or mention any preconditions such as calling xdr_get_mapping first, so guidance remains implied.

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