Skip to main content
Glama
Sign In
alexgoller

Illumio MCP Server

by alexgoller
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

discover-process-egress

Identify processes connecting to external destinations outside PCE-managed estate; returns ranked shadow-IT findings with ports, user, policy decision, and volume.

Instructions

Find which processes talk to destinations outside this PCE's managed estate - the shadow-IT / unsanctioned-egress question. Returns ranked findings of process -> external destination with port, protocol, the user, current policy decision and volume, preferring an FQDN over a bare IP where the PCE resolved one. Use this instead of get-traffic-flows when the question is 'what is talking out', not 'show me all traffic'.

Input Schema

NameRequiredDescriptionDefault
limitNoMax findings returned. Default 50.
processNoOnly these processes. Substring, case-insensitive, e.g. ['claude','chrome']. Omit for all.
end_dateNoEnd (YYYY-MM-DD). Defaults to now.
start_dateNoStart (YYYY-MM-DD). Overrides lookback_days.
max_resultsNoMax flows to pull from the PCE. Capped at 500.
lookback_daysNoDays to look back. Default 7. Ignored if start_date is given.
include_sourcesNoRestrict to these sources. Accepts label shorthand 'key=value' (e.g. 'app=vdi'), label/IP list/workload HREFs or IPs (FQDNs are destination-only).
policy_decisionsNoFilter by decision, e.g. ['allowed'] to show only egress current policy permits.
only_named_processesNoDefault true. When false, also returns egress with no process attribution (the PCE only reports process names where the VEN has process visibility enabled).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.13.0
    • changedInput schema / properties / include_sources / description
      Previous value: -"Restrict to these sources. Accepts label shorthand 'key=value' (e.g. 'app=vdi'), HREFs, IPs or FQDNs."New value: +"Restrict to these sources. Accepts label shorthand 'key=value' (e.g. 'app=vdi'), label/IP list/workload HREFs or IPs (FQDNs are destination-only)."
  2. Addedv0.8.0

TDQS

A4.4/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 and mostly does: it discloses the return record shape (process -> external destination with port, protocol, user, policy decision, volume), the ranking behavior, and the FQDN-over-bare-IP preference. It does not state that the operation is read-only or whether results are scoped by PCE permissions, which is the remaining gap for a zero-annotation 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?

Two sentences, front-loaded with the core question, then the return shape, then the disambiguation against the sibling. No filler and nothing 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 nine-parameter, zero-annotation tool with no output schema, the description supplies the return contract and the selection rule, which is what an agent most needs. Missing are permission/scope caveats and the only_named_processes attribution caveat, which currently lives only in the schema.

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 100%, so all nine parameters are already documented in the schema, making 3 the baseline. The description adds one genuinely useful cross-parameter constraint implicitly by noting FQDNs only apply to destinations, but it does not explain limit vs max_results or when to prefer lookback_days over start_date beyond what the schema says.

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 concrete verb and resource ('Find which processes talk to destinations outside this PCE's managed estate') and frames it as the shadow-IT/unsanctioned-egress question. It also explicitly distinguishes itself from get-traffic-flows, so an agent can pick between them 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?

Gives an explicit routing rule: use this instead of get-traffic-flows when the question is 'what is talking out', not 'show me all traffic'. That is a when-to-use plus a named alternative plus the condition that selects it.

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