Illumio MCP Server

get-traffic-flows-summary

Summarize traffic flows into structured JSON grouped by process, external destination, blocked status, and app-to-app. Provides compact analysis over the full time window, answering common questions directly.

Instructions

Summarize traffic flows as structured JSON. Sections: by_process (which binary talks to which destination, on which port, under which policy, and as which user), external_destinations (traffic leaving the managed estate), blocked (what policy is stopping), app_to_app (coarse view). Prefer this over get-traffic-flows for analysis - it is far smaller and answers the usual questions directly.

Input Schema

TableJSON Schema

Name	Required	Description
`end_date`	Yes	Ending datetime (YYYY-MM-DD or timestamp)
`query_name`	No
`start_date`	Yes	Starting datetime (YYYY-MM-DD or timestamp)
`max_results`	No
`detail_level`	No	How much of each section to show. 'standard' (default) shows the top 100 per section; 'full' shows everything that fits the response limit, which can be ~10x the tokens. Analysis always covers the WHOLE window either way -- totals and section_totals are computed over every row, so the numbers are identical; only the displayed rows differ.
`exclude_sources`	No	Sources to exclude (label/IP list/workload HREFs, FQDNs, IPs). Best case these are hrefs like /orgs/1/labels/57 or similar. Other way is app=env as an example (label key and value)
`identity_labels`	No	Label dimensions that define an endpoint's identity in app_to_app. Defaults to ['app','env'] because that is how Illumio defines an application, but ANY label this PCE defines works: ['bu'] for a business-unit view, ['compliance','env'] for a compliance view, ['role','loc'] for a tiered one. The response's available_dimensions lists what this PCE actually has.
`include_sources`	No	Sources to include (label/IP list/workload HREFs, FQDNs, IPs). Best case these are hrefs like /orgs/1/labels/57 or similar. Other way is app=env as an example (label key and value)
`exclude_services`	No
`include_services`	No
`policy_decisions`	No
`exclude_destinations`	No	Destinations to exclude (label/IP list/workload HREFs, FQDNs, IPs). Best case these are hrefs like /orgs/1/labels/57 or similar. Other way is app=env as an example (label key and value)
`include_destinations`	No	Destinations to include (label/IP list/workload HREFs, FQDNs, IPs). Best case these are hrefs like /orgs/1/labels/57 or similar. Other way is app=env as an example (label key and value)
`exclude_workloads_from_ip_list_query`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.8.0Sep 18, 2026

addedInput schema / properties / detail_level

Added value: +{
+  "description": "How much of each section to show. 'standard' (default) shows the top 100 per section; 'full' shows everything that fits the response limit, which can be ~10x the tokens. Analysis always covers the WHOLE window either way -- totals and section_totals are computed over every row, so the numbers are identical; only the displayed rows differ.",
+  "enum": [
+    "standard",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / identity_labels

Added value: +{
+  "description": "Label dimensions that define an endpoint's identity in app_to_app. Defaults to ['app','env'] because that is how Illumio defines an application, but ANY label this PCE defines works: ['bu'] for a business-unit view, ['compliance','env'] for a compliance view, ['role','loc'] for a tiered one. The response's available_dimensions lists what this PCE actually has.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Addedv1.0.0Jan 2, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It explicitly says the output is structured JSON, describes each section, and notes that the result is smaller than the sibling. It does not explicitly state read-only or auth requirements, but the 'get/summarize' verbs and non-destructive framing convey query behavior. No contradictions.

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?

The description is a single compact paragraph that front-loads the core function, then lists output sections, then gives a decision rule. Every sentence carries information and there is no padding.

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 14-parameter tool with no output schema or annotations, the description is not fully complete: it covers the output shape and the sibling distinction well, but it does not explain how filters, max_results, query_name, or policy_decisions affect the summary. The schema fills in some gaps, but several ambiguous parameters remain, so an agent may still need to infer behavior.

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

Parameters2/5

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

The description provides no parameter-level guidance. Schema coverage is only 57%, leaving params like query_name, max_results, include/exclude_services, and exclude_workloads_from_ip_list_query without descriptions in either the schema or the tool description. The description's sections don't map to any input parameter, so it fails to compensate for the coverage gap.

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?

The verb 'Summarize' plus resource 'traffic flows' makes the action and target explicit. Enumerating the four JSON sections (by_process, external_destinations, blocked, app_to_app) gives an agent a clear picture of what it will receive. It also explicitly differentiates from get-traffic-flows, so the purpose is unambiguous.

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?

'Prefer this over get-traffic-flows for analysis' is an explicit routing instruction that names the sibling and the condition. The rationale ('far smaller and answers the usual questions directly') helps an agent decide correctly without needing to inspect get-traffic-flows.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

get-traffic-flows-summary

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools