Skip to main content
Glama
Sign In
Illumio MCP Server

Illumio MCP Server

by alexgoller
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get-events

Retrieve and filter Illumio PCE audit events by type, kind, creator, status, severity, or time range to inspect policy, enforcement, VEN, and auth activity.

Instructions

PCE audit events as data. Each event carries created_by as {type: user|agent|system, username, href}, resource_changes as [{resource_type, href, name, change_type, changes}] (which ruleset, rule, workload... changed and how), notifications as [{notification_type, info}] and action as {api_endpoint, api_method, src_ip, http_status_code}. Filter by event_type (one string or a list, ORed) or by kind: policy = sec_policy.create/restore, rule_set., sec_rule., deny_rule., ip_list., service.* (create/update/delete); enforcement = workloads.bulk_update / workload.update whose changes name enforcement_mode; ven = agent.activate/deactivate/tampering/clone_detected/suspend/unsuspend, workloads.unpair; auth = user.login/logout/sign_in/sign_out/authenticate, request.authorization_failed. Verified on a live PCE (26.30): rule_set., sec_rule.create/delete, deny_rule., ip_list., service., workloads.bulk_update, request.authorization_failed. The rest are Illumio's documented names not yet seen on a PCE (expected); event_types_unverified lists them per call. The PCE filters on one event_type per request, so a list or kind is one request per type, merged newest-first and capped at max_results; event_types_queried echoes the list.

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-events"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoNamed group of event types: policy (provisioning, ruleset/rule/ip list/service changes), enforcement (enforcement mode changes), ven (pairing/unpairing/tampering), auth (user login/logout). See the tool description for the exact strings.
statusNoFilter by event status
severityNoFilter by event severity
created_byNoFilter by creator (user, agent, or system)
event_typeNoEvent type string, or a list of them (OR). E.g. 'sec_policy.create' or ['rule_set.update', 'sec_rule.update']. Combines with kind.
max_resultsNoMaximum number of events to return
timestamp_gteNoEarliest event timestamp (RFC 3339 format)
timestamp_lteNoLatest event timestamp (RFC 3339 format)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.13.0
    • addedInput schema / properties / event_type / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
    • changedInput schema / properties / event_type / description
      Previous value: -"Filter by event type (e.g., 'system_task.expire_service_account_api_keys')"New value: +"Event type string, or a list of them (OR). E.g. 'sec_policy.create' or ['rule_set.update', 'sec_rule.update']. Combines with kind."
    • removedInput schema / properties / event_type / type
      Removed value: -"string"
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "Named group of event types: policy (provisioning, ruleset/rule/ip list/service changes), enforcement (enforcement mode changes), ven (pairing/unpairing/tampering), auth (user login/logout). See the tool description for the exact strings.",
+  "enum": [
+    "policy",
+    "enforcement",
+    "ven",
+    "auth"
+  ],
+  "type": "string"
+}
  2. Changed3 schema fields changedv0.8.0
    • addedInput schema / properties / created_by
      Added value: +{
+  "description": "Filter by creator (user, agent, or system)",
+  "type": "string"
+}
    • addedInput schema / properties / timestamp_gte
      Added value: +{
+  "description": "Earliest event timestamp (RFC 3339 format)",
+  "type": "string"
+}
    • addedInput schema / properties / timestamp_lte
      Added value: +{
+  "description": "Latest event timestamp (RFC 3339 format)",
+  "type": "string"
+}
  3. Addedv1.0.0

TDQS

A4.1/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 does well: it discloses the per-request single-event-type PCE constraint, one-request-per-type fan-out, newest-first merging, max_results capping, and that event_types_queried echoes the list. It also flags which event names are verified versus merely documented, which is unusually candid. It still omits permission requirements, default time window, and whether results are read-only in practice.

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?

Front-loads the purpose and payload, then moves to filtering, verification status, and request semantics. The single dense paragraph wastes little, though the verification caveat and request-fan-out details could be split for readability. Every sentence carries information.

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?

No output schema exists, so the description must convey return values; it partially does by describing created_by, resource_changes, notifications, action, and the event_types_queried/unverified fields. It does not describe the full response envelope, pagination tokens, or default time range, which leaves some gaps for an 8-parameter tool, but the critical invocation semantics are covered.

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 100%, so the baseline is 3, and the description adds real value: it defines exactly which event_type strings belong to each kind, explains that event_type accepts a single string or an ORed list, that kind and event_type combine, and how max_results interacts with the fan-out. It does not add much on status, severity, created_by, or the timestamp parameters beyond what the schema already 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 specific verb and resource: 'PCE audit events as data', then enumerates the event payload fields. An agent immediately knows this retrieves audit event records, which no sibling tool does. Distinguishable from the policy/workload CRUD and traffic-flow siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Extensive guidance on how to filter (kind vs event_type, OR semantics) but no explicit statement of when to use this tool versus alternatives, or when not to use it. Usage is implied by the audit-event framing, but there is no named alternative or exclusion.

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