Skip to main content
Glama
Sign In
Illumio MCP Server

Illumio MCP Server

by alexgoller
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

build-identity-graph

Maps which accounts reach which workloads and destinations over time, unifying domain and UPN identities and separating service accounts to support least-privilege access reviews.

Instructions

Identity-centric view of traffic: which ACCOUNT the communicating process ran as, which workloads it acted from, what it reached, and over what period. Answers least-privilege questions that workload labels cannot -- what can this account reach, and from how many places. Resolves DOMAIN\user and user@realm to one identity, so a person appearing as both CRYSTAL\jdoe and jdoe is not counted twice. Classifies service accounts (root, SYSTEM, mysql) separately from interactive ones, because wide host spread is normal for a daemon and notable for a person. Findings are ranked by how unexpected they are, and are observations, not verdicts.

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": "build-identity-graph"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNoDestinations/ports/processes listed per identity (default 10)
end_dateNoYYYY-MM-DD; defaults to today
identityNoRestrict to these accounts. Domain-qualified or bare both work: 'CRYSTAL\jdoe' and 'jdoe' select the same identity.
start_dateNoYYYY-MM-DD; defaults to lookback_days ago
include_edgesNoInclude the identity -> workload -> destination edges. Capped at 400, ranked by connections; the identity rollup answers most questions without them.
lookback_daysNoUsed when start_date is omitted (default 30)
include_sourcesNoSource filters: label HREFs or key=value (ANDed), IP list/workload HREFs, IPs, e.g. ['app=vdi']
policy_decisionsNoallowed, blocked, potentially_blocked
include_destinationsNoDestination filters, same forms as include_sources plus FQDNs
include_service_accountsNoInclude daemon accounts (root, SYSTEM, mysql, ...). Default true. Set false to look only at interactive users.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.13.0
    • changedInput schema / properties / include_destinations / description
      Previous value: -"Label filters on the destination side"New value: +"Destination filters, same forms as include_sources plus FQDNs"
    • changedInput schema / properties / include_sources / description
      Previous value: -"Label filters, e.g. ['app=vdi']"New value: +"Source filters: label HREFs or key=value (ANDed), IP list/workload HREFs, IPs, e.g. ['app=vdi']"
  2. Addedv0.11.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden well: it explains identity normalization, separate handling of service accounts, ranking of findings by unexpectedness, and that results are observations rather than verdicts. It does not cover permissions, performance limits, or output shape in detail, but the key interpretive behavior is disclosed.

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 description is dense but mostly front-loaded, starting with the identity-centric view and then explaining differentiation, identity resolution, service-account handling, and ranking caveats. Each sentence contributes useful context, though it is longer than strictly necessary for a well-described schema.

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 ten-parameter analysis tool with no output schema and no annotations, the description provides the conceptual model an agent needs: what is analyzed, how identities are normalized, how service accounts are treated, and how findings are ranked. It lacks explicit output structure details, but the schema covers parameter mechanics and the description covers interpretation.

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 all ten parameters are already documented. The description reinforces the identity-resolution and service-account concepts that matter for interpretation, but adds little parameter-specific syntax or constraints beyond what the schema provides.

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 clearly establishes an identity-centric traffic view and enumerates what it reports: account, workloads, destinations, and time period. It distinguishes itself from workload-label-based views, but does not explicitly name a sibling tool or use a direct verb phrase such as 'builds an identity graph.'

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 clear usage context: answering least-privilege questions about what an account can reach and from how many places, especially where workload labels fall short. It does not provide explicit exclusions or point to named alternative tools for overlapping traffic-analysis tasks.

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