Illumio MCP Server

get-traffic-fingerprint

Capture a snapshot of which applications and services communicate across an org, environment, or app, then compare it to an earlier baseline to surface new, changed, and gone traffic peers and drift per app.

Instructions

A snapshot of who talks to whom on which service -- for the whole org, one environment (scope={env}) or one app (scope={app, env}) -- and the drift against an earlier snapshot. One Explorer query over the window; keys are app-pair x service with the decision set seen (A allowed, P potentially blocked, B blocked), never counts, plus per-app shape: peers in/out, external destinations and sources, services, blocked share, attributed providers. Compare by passing baseline (the fingerprint object this tool returned before) or baseline_days (a second query over the N days before the window): new / changed / gone keys, drift per app, the peers and providers that came and went. A compare across another PCE, org, scope or identity axis is refused; unequal windows and truncated sides are warned, since they inflate new or gone. Use it for 'what changed in payments/prod since last month', 'is this environment's shape stable', or to keep a per-app history.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get-traffic-fingerprint"
  }
}

Input Schema

Name	Required	Description
`scope`	No	{app, env} for one app, {env} for an environment, omit for the org
`baseline`	No	A `fingerprint` object returned by this tool earlier, to compare against. Must be of the same PCE, scope and identity_labels and carry its keys
`end_date`	No	YYYY-MM-DD or ISO-8601 timestamp; defaults to today
`start_date`	No	YYYY-MM-DD or ISO-8601 timestamp; defaults to lookback_days ago
`max_results`	No	Row cap per query (default 200000); a hit is recorded in coverage.truncated
`baseline_days`	No	Instead of `baseline`: also query the N days immediately before the window and compare against that (1..365). Equal to the window length for a like-for-like compare
`lookback_days`	No	Used when start_date is omitted (default 7)
`identity_labels`	No	Label keys that identify an app (default [app, env])
`policy_decisions`	No	Restrict both windows to these decisions (recorded in basis.filters)
`exclude_workloads_from_ip_list_query`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.15.0Nov 12, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations at all, the description carries the full burden and does so: it discloses refusal behavior for cross-PCE/org/scope/identity-axis compares, warning behavior for unequal windows and truncated sides, truncation recorded in coverage.truncated, and the fact that both windows are filtered by policy_decisions recorded in basis.filters. These are non-obvious operational traits an agent cannot get from the schema alone.

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?

The core purpose is front-loaded in the first clause and nearly every sentence adds real information, but the single run-on paragraph with heavy parentheticals and em-dash asides makes it denser than it needs to be for scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with no output schema, the description compensates by describing the return shape (app-pair x service keys, decision set, per-app peers in/out, external destinations, blocked share, attributed providers) and the drift sections (new/changed/gone, per-app drift, peers and providers gained/lost). An agent has enough to call it and to interpret what comes back.

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

Parameters4/5

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

Schema coverage is 90%, so the baseline is 3; the description rises above it by explaining scope resolution ({app, env} vs {env} vs org), the constraint that `baseline` must match PCE/scope/identity_labels, and the advice that baseline_days should equal the window length for a like-for-like compare. `exclude_workloads_from_ip_list_query` remains unexplained in both places.

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 names a concrete artifact with precise semantics: a snapshot of 'who talks to whom on which service' keyed by app-pair x service with a decision set (A/P/B) and explicitly 'never counts'. That contrasts implicitly with the flow/count-oriented siblings, but no sibling is named or directly disambiguated, so the differentiation stays inferential rather than stated.

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?

It gives explicit scenario guidance ('what changed in payments/prod since last month', 'is this environment's shape stable', 'keep a per-app history') and tells the agent which comparison mode to pick for like-for-like results. What is missing is a when-not-to-use statement routing to get-traffic-flows, get-traffic-flows-summary, or get-traffic-timeline.

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

Deploy Server