Skip to main content
Glama
Illumio MCP Server

Illumio MCP Server

by alexgoller

get-traffic-flows-summary

Summarize traffic flows into structured JSON for process, external destination, blocked traffic, and app-to-app analysis, avoiding large raw flow responses.

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start_date": "<start_date>",
      "end_date": "<end_date>"
    },
    "name": "get-traffic-flows-summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
end_dateYesEnding datetime (YYYY-MM-DD or timestamp)
query_nameNo
start_dateYesStarting datetime (YYYY-MM-DD or timestamp)
max_resultsNo
detail_levelNoHow 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_sourcesNoSources to exclude (label/IP list/workload HREFs, IPs; FQDNs are destination-only). 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_labelsNoLabel 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_sourcesNoSources to include (label/IP list/workload HREFs, IPs; FQDNs are destination-only). 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_servicesNo
include_servicesNo
policy_decisionsNo
exclude_destinationsNoDestinations 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_destinationsNoDestinations 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_queryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.13.0
    • changedInput schema / properties / exclude_sources / description
      Previous value: -"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)"New value: +"Sources to exclude (label/IP list/workload HREFs, IPs; FQDNs are destination-only). Best case these are hrefs like /orgs/1/labels/57 or similar. Other way is app=env as an example (label key and value)"
    • changedInput schema / properties / include_sources / description
      Previous value: -"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)"New value: +"Sources to include (label/IP list/workload HREFs, IPs; FQDNs are destination-only). Best case these are hrefs like /orgs/1/labels/57 or similar. Other way is app=env as an example (label key and value)"
  2. Changed2 schema fields changedv0.8.0
    • 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"
      +}
  3. Addedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations present, the description carries the full disclosure burden, and it delivers the most important behavioral fact for an agent: the response shape (four named sections) and the cost tradeoff versus the raw flows tool. It stops short of stating permission/auth requirements, the hard response size limit, or pagination behavior, which leaves real gaps for a heavy read tool.

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 sentences, front-loaded with the action and return shape, and the section enumeration earns its length by telling the agent exactly what analysis it can answer without a follow-up call. No filler.

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?

This is a 14-parameter tool with no output schema and no annotations, so the description has to compensate, and it largely does by describing the four output sections in useful detail. The filtering surface (most of those 14 params) remains under-explained, both in the description and partly in the schema, which is the one meaningful shortfall.

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 coverage is 57%, so roughly half the 14 parameters lean on the schema alone. The description adds only an implicit hint about detail_level cost ("far smaller") and says nothing about query_name, max_results, policy_decisions, the include/exclude service pairs, or exclude_workloads_from_ip_list_query. Baseline 3 for a mid-coverage schema is appropriate here.

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?

States a specific verb and resource ("Summarize traffic flows as structured JSON") and then enumerates the exact sections returned (by_process, external_destinations, blocked, app_to_app). It also explicitly positions itself against the sibling get-traffic-flows, so an agent can distinguish the two without opening either schema.

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?

Names the alternative tool by name and gives the selection condition: use this for analysis because it is far smaller and answers the usual questions directly. The only minor omission is a reverse pointer back to get-traffic-flows for raw row-level detail, but the routing guidance is explicit and actionable.

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