Skip to main content
Glama
Sign In
F6 XDR MCP Server

F6 XDR MCP Server

Official
by F6-Security
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

xdr_search

Read-only

Search XDR sections for matching events and objects using field:value queries; returns filtered records so you can locate alerts, incidents, assets, and logs.

Instructions

Search for events/objects in an XDR section. Returns matching records; an empty query returns the section unfiltered. Use xdr_get_mapping first to discover available fields.

Input Schema

NameRequiredDescriptionDefault
queryYesSearch 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.
offsetNoNumber of results to skip. For the "modules" section the API pages in fixed steps, so offset must be a multiple of page_size there.
sectionYesSection name, one of: alerts, incidents, emails, files, events, connections, assets, modules, audit, applications, application_versions
orderingNoSort field with optional - prefix for descending, e.g. -created_at (newest first). An unknown field is silently ignored: the API reports no error and the results come back in some other order, so use only the fields listed here. Per section — alerts: created_at, last_event, last_updated, severity; incidents: created_at, updated_at; emails: ts_created, delay; files: ts_created, delay; events: Header.Timestamp; connections: ts_parsed, ts_last_usage_parsed, service_count, duration; assets: last_activity, first_activity; modules: ts_created, name; audit: timestamp; applications: name, ts_created, ts_updated; application_versions: version, ts_created, ts_updated.
page_sizeNoNumber of results per page (1-200, default 10)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.3.0
    • changedInput schema / properties / ordering / description
      Previous value: -"Sort field with optional - prefix for descending, e.g. -created_at (newest first). An unknown field is silently ignored: the API reports no error and the results come back in some other order, so use only the fields listed here. Per section — alerts: created_at, last_event, last_updated, severity; incidents: created_at, updated_at; emails: ts_created, delay; files: ts_created, delay; events: Header.Timestamp; connections: ts_parsed, ts_last_usage_parsed, service_count, duration; assets: last_activity, first_activity; modules: ts_created, name; audit: timestamp; applications: name, ts_created, ts_updated."New value: +"Sort field with optional - prefix for descending, e.g. -created_at (newest first). An unknown field is silently ignored: the API reports no error and the results come back in some other order, so use only the fields listed here. Per section — alerts: created_at, last_event, last_updated, severity; incidents: created_at, updated_at; emails: ts_created, delay; files: ts_created, delay; events: Header.Timestamp; connections: ts_parsed, ts_last_usage_parsed, service_count, duration; assets: last_activity, first_activity; modules: ts_created, name; audit: timestamp; applications: name, ts_created, ts_updated; application_versions: version, ts_created, ts_updated."
    • 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."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."
    • 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

A4/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 known. The definition goes beyond that with non-obvious behaviors: an empty query returns the section unfiltered and may be very large, an unparseable query is silently treated as free text rather than rejected, and an unknown ordering field is silently ignored — all important silent-failure disclosures.

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 purpose, then return behavior, then the prerequisite call. Nothing is redundant or 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 complex, 11-section search tool, the definition covers purpose, return shape, empty-query semantics, and the discovery path through xdr_get_mapping/xdr_get_filters/xdr_get_suggestions. With no output schema, a brief note on what a result record looks like would fully close the gap.

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 is already documented in detail, including query syntax, per-section ordering fields, and the modules offset constraint. The top-level description adds no parameter meaning beyond the schema, 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?

States a specific verb and resource: search for events/objects within an XDR section, returning matching records. It names the sibling it depends on (xdr_get_mapping) but does not explicitly distinguish itself from xdr_count, which an agent could reasonably confuse with this tool.

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?

Gives clear context: call xdr_get_mapping first to learn the fields, and pass an empty query only when the whole section is intentionally wanted. The schema text further routes to xdr_get_filters and xdr_get_suggestions, but no explanation of when to prefer xdr_count over a search is given.

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