Illumio MCP Server

📚 Documentation site — installation, getting started, workflows, the full tool reference, and central deployment.

A Model Context Protocol (MCP) server that provides an interface to interact with Illumio PCE (Policy Compute Engine). This server enables programmatic access to Illumio workload management, label operations, traffic flow analysis, automated ringfencing, and infrastructure service identification.

What can it do?

Use conversational AI to talk to your PCE:

• Full CRUD on workloads, labels, IP lists, services, and rulesets

• Traffic analysis over the whole window — summaries aggregate every flow the PCE returns, not the first 500, and report how much exists vs how much is shown

• Aggregate on any label — app/env by default, or business unit, compliance scope, role+location; whatever dimensions your PCE defines

• Shadow-AI / egress discovery — which process talks to which provider, with attribution from RDAP and vendor-published ranges refreshed weekly in CI

• Process-qualified policy — "only this binary may reach that app", via Windows egress services and service references in rules

• Automated ringfencing — analyze traffic and create app-to-app segmentation policies with one command

• Selective enforcement — add deny rules for apps in selective mode with configurable consumer flavors

• Infrastructure service identification — discover which apps are infrastructure services using graph centrality analysis, so you know what to policy first

• Deny rule management — create, update, and delete deny rules (including override deny for emergencies)

• Rules editable in place — update-sec-rule / delete-sec-rule instead of rebuilding a ruleset

• Event monitoring — query PCE events with severity and type filters

• PCE health checks — verify connectivity and credentials

• Tells you when it changed — get-server-changelog reports behaviour changes to a session whose cached tool list is stale

Related MCP server: OpenCTI MCP Server

Prerequisites

• Python 3.12 or 3.13 (see requires-python in pyproject.toml)

• Access to an Illumio PCE instance

• Valid API credentials for the PCE

Installation

1. Clone the repository:

git clone https://github.com/alexgoller/illumio-mcp-server.git
cd illumio-mcp-server

2. Install dependencies:

uv sync

Configuration

You should run this using the uv command, which makes it easier to pass in environment variables and run it in the background.

Using uv and Claude Desktop

On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json On Windows: %APPDATA%/Claude/claude_desktop_config.json

Add the following to the custom_settings section:

"mcpServers": {
    "illumio-mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/illumio-mcp-server",
        "run",
        "illumio-mcp"
      ],
      "env": {
        "PCE_HOST": "your-pce-host",
        "PCE_PORT": "your-pce-port",
        "PCE_ORG_ID": "1",
        "API_KEY": "api_key",
        "API_SECRET": "api_secret"
      }
    }
  }
}

No clone: run it with uvx

uvx builds the server from GitHub into its cache and runs the console script; nothing to clone, no virtualenv to manage, and a tag pins the version:

uvx --env-file /path/to/illumio.env \
    --from "git+https://github.com/alexgoller/illumio-mcp-server@v0.13.1" illumio-mcp

--env-file is how credentials reach it: there is no repository directory, so the usual .env auto-load does not happen. Use @main for the latest, and uvx --refresh … when a tag moves or you want a fresh build; the first run compiles the package (~15 s), later runs start in under a second. Verified end to end on 2026-11-06: 55 tools, check-pce-connection ok.

Register it with Claude Code the same way, replacing the uv --directory form:

claude mcp add -s user illumio-mcp \
  -- uvx --env-file /path/to/illumio.env \
     --from "git+https://github.com/alexgoller/illumio-mcp-server@v0.13.1" illumio-mcp

Claude Desktop needs the absolute path to uvx (it does not inherit your shell's PATH); which uvx tells you (/opt/homebrew/bin/uvx on a Homebrew Mac):

"illumio-mcp": {
  "command": "/opt/homebrew/bin/uvx",
  "args": ["--env-file", "/path/to/illumio.env",
           "--from", "git+https://github.com/alexgoller/illumio-mcp-server@v0.13.1",
           "illumio-mcp"]
}

Using with Claude Code

One command registers the server as a stdio MCP server for Claude Code. Replace the path and the five PCE values; -s user makes it available in every project (-s project writes a shareable .mcp.json into the current repo instead -- do not put real credentials in that one).

claude mcp add -s user illumio-mcp \
  -e PCE_HOST=https://your-pce.example.com \
  -e PCE_PORT=443 \
  -e PCE_ORG_ID=1 \
  -e API_KEY=api_xxxxxxxxxxxxxxxx \
  -e API_SECRET=your_api_secret \
  -- uv --directory /path/to/illumio-mcp-server run illumio-mcp

Optional: -e PCE_TLS_VERIFY=false for a self-signed PCE certificate, and -e MCP_LOG_LEVEL=DEBUG while diagnosing (the log is illumio-mcp.log in the repo directory, because --directory makes it the working directory).

Verify, then ask Claude Code to call check-pce-connection:

claude mcp get illumio-mcp      # Status: ✔ Connected, and the env you set
claude mcp list                 # every server and whether it connects
claude mcp remove -s user illumio-mcp   # to undo

Already have a .env in the repo? The server loads it from the working directory, so with --directory set you can omit the -e flags entirely -- but the file then holds the secrets, so keep it out of git (it is in .gitignore).

HTTP transport with OAuth Resource Server (Phase 3a)

The server runs over HTTP using the MCP Streamable HTTP transport (spec rev 2025-03-26) and validates OAuth 2.1 bearer tokens issued by your IdP. This is Phase 3a: identity is enforced; per-user PCE keys land in Phase 3b.

Running with auth (production-shaped)

export MCP_PUBLIC_URL=https://mcp.illumio.example
export MCP_OAUTH_ISSUER=https://login.microsoftonline.com/<tenant-id>/v2.0
export MCP_OAUTH_JWKS_URL=https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keys
export MCP_OAUTH_AUDIENCE=https://mcp.illumio.example
export MCP_OAUTH_REQUIRED_SCOPE=illumio-mcp.use   # default; override if needed
illumio-mcp-http --host 127.0.0.1 --port 8080

The server refuses to start without these env vars (unless MCP_DEV_INSECURE=1).

MCP clients discover the AS via the standard RFC 9728 endpoint:

GET /.well-known/oauth-protected-resource

Unauthenticated requests to /mcp return 401 with WWW-Authenticate: Bearer resource_metadata="<URL>", which any spec-compliant MCP client (Claude Desktop, ChatGPT, MCP Inspector) follows automatically to run PKCE auth code flow against the configured AS.

Running without auth (dev only)

MCP_DEV_INSECURE=1 illumio-mcp-http

The server logs a prominent warning. Do NOT use in production.

Health endpoints (always unauthenticated)

• GET /healthz — liveness

• GET /readyz — readiness (Phase 3a returns the same as healthz; Phase 3b/c will add PCE + JWKS reachability)

Two PCE modes (Phase 3b vs Phase 3e)

The HTTP server supports three ways to source PCE credentials, selected via MCP_PCE_MODE:

Choose per-user when:

• You want PCE-side audit attribution to identify the human

• Users are happy to provide their own PCE API key once

• You can tolerate the per-user PCE key sprawl (PCE has limits)

Choose shared when:

• The PCE limits API keys per user too aggressively for per-user mode

• You want zero-friction onboarding (no /setup step)

• You're OK relying on the MCP audit log alone for human-level attribution

• You operate the PCE service account yourself and rotate it on a schedule

Choose hybrid when:

• You rolled out in shared mode and want a stepwise migration to per-user

• Compliance needs named PCE-side attribution for some users without forcing everyone to onboard

• You accept that the PCE audit log is mixed, and will read effective_pce_mode in the MCP audit log

Hybrid requires both the shared env (PCE_*, API_*) and MCP_KEK; it refuses to start without either. check-pce-credentials-status reports the mode that applies to the calling user for this request — including the case where their stored key exists but could not be used and the call ran as the service account.

In shared mode, /setup is not mounted, the credential-management tools (register-pce-credentials, delete-pce-credentials) refuse with a friendly error, and MCP_KEK is not required. SSO + JWT + role-based authz + audit log + confirm tokens all still apply identically.

# Shared mode — same env that stdio uses today, plus auth/role config
export MCP_PCE_MODE=shared
export PCE_HOST=https://your-pce.example.com
export PCE_PORT=8443
export PCE_ORG_ID=1
export API_KEY=your_pce_api_key_name
export API_SECRET=your_pce_api_key_secret
# (other auth/role env vars from earlier sections still apply)
illumio-mcp-http

Per-user PCE keys (Phase 3b)

Each authenticated user has their own PCE API key/secret stored in an encrypted SQLite keystore. PCE-side audit logs attribute correctly per human; revoking a user is a single tool call.

Additional env required when running with auth:

export MCP_KEK=$(python -c 'import os, base64; print(base64.b64encode(os.urandom(32)).decode())')
export MCP_KEYSTORE_PATH=/var/lib/illumio-mcp/keys.db   # default: ./data/keys.db

The KEK is never stored next to the database. Loss of KEK = total loss of stored creds (intentional, fail-closed). For production, source MCP_KEK from KMS or Vault rather than the operator's shell.

Onboarding paths (either works):

1. Browser — visit /setup after authenticating; paste credentials in the form.

2. MCP client — call the register-pce-credentials tool; the only tool available before credentials are registered.

Other credential tools:

• check-pce-credentials-status — does this user have credentials registered?

• delete-pce-credentials — remove this user's credentials.

Role-based authorization (Phase 3c)

The server maps each user's IdP groups to one of three internal roles: reader, operator, admin. Per-tool authorization is enforced by the dispatcher using the roles metadata on each ToolSpec.

Configure group → role mapping via env (comma-separated):

# A user matching ANY of these groups gets that role; highest role wins.
export MCP_ROLE_GROUPS_ADMIN=sg-illumio-mcp-admin
export MCP_ROLE_GROUPS_OPERATOR=sg-illumio-mcp-operator,sg-illumio-mcp-admin
export MCP_ROLE_GROUPS_READER=sg-illumio-mcp-readonly,sg-illumio-mcp-operator,sg-illumio-mcp-admin

# Optional: fallback role when no group matches. Leave unset to refuse.
# export MCP_ROLE_DEFAULT=reader

Tool-by-tool defaults:

A user without a matching role (and no MCP_ROLE_DEFAULT) receives a structured forbidden_no_role error.

Audit log (Phase 3c)

Every dispatcher decision (allow / deny / error) is written to a SQLite audit database. Schema and storage location:

# Defaults to <keystore_dir>/audit.db
export MCP_AUDIT_LOG_PATH=/var/lib/illumio-mcp/audit.db

Audit rows include (ts, sub, iss, tool, decision, reason, role, request_id) — never tool arguments. The request_id matches the X-Request-Id response header so external traces can be correlated.

Query examples:

-- Recent denied calls per user
SELECT ts, sub, tool, reason FROM audit_log
WHERE decision='denied'
ORDER BY ts DESC LIMIT 20;

-- Tool-call volume by user
SELECT sub, COUNT(*) FROM audit_log
WHERE ts > date('now', '-7 days')
GROUP BY sub ORDER BY 2 DESC;

Confirm tokens for mutating tools (Phase 3d)

Tools marked requires_confirm=True (currently provision-policy, ringfence-batch, register-pce-credentials, delete-pce-credentials) require a server-issued single-use confirm token in params._meta.confirm_token when called over HTTP. Stdio mode is unaffected — the operator who launched the process can call mutating tools directly.

Required env in auth mode:

export MCP_CONFIRM_HMAC_KEY=$(python -c 'import os, base64; print(base64.b64encode(os.urandom(32)).decode())')
# Optional:
# export MCP_CONFIRM_TTL_SECONDS=120
# export MCP_CONFIRM_JTI_PATH=/var/lib/illumio-mcp/jti.db
# export MCP_CONFIRM_FRESH_AUTH_SECONDS=300   # require JWT auth_time within 5 min

How a client uses it

1. Call the mutating tool without a token → server returns:

   {"error": "confirm_required", "params_hash": "<sha256>", "message": "..."}

2. Call POST /confirm with the JWT and the params_hash:

   curl -X POST https://mcp.illumio.example/confirm \
     -H "Authorization: Bearer $JWT" \
     -H "Content-Type: application/json" \
     -d '{"tool":"provision-policy","params_hash":"<sha256>"}'
   # → {"confirm_token": "...", "expires_in": 120}

3. Re-call the tool with the token in params._meta.confirm_token.

Tokens are single-use (replays return confirm_token_replay) and scoped to (sub, tool, params_hash). Tampering with any field invalidates the token.

Step-up auth (optional, recommended for production)

Set MCP_CONFIRM_FRESH_AUTH_SECONDS=300 to require the JWT's auth_time claim to be within the last 5 minutes. Forces the user to re-authenticate before minting a token — the strongest prompt-injection defense available without an interactive session model. Requires the IdP to issue auth_time (Entra and Okta both do for OIDC sign-in flows).

Tools

Workload Management

• get-workloads — Retrieve workloads with optional filtering by name, hostname, IP, labels, and max results

• create-workload — Create an unmanaged workload with name, IP addresses, and labels

• update-workload — Update an existing workload's properties

• delete-workload — Remove a workload from PCE

Label Operations

• get-labels — Retrieve labels with optional filtering by key, value, and max results

• create-label — Create a new label with key-value pair

• update-label — Update an existing label

• delete-label — Remove a label

Ruleset & Rule Management

• get-rulesets — Get rulesets with optional filtering by name, description, and enabled status

• create-ruleset — Create a new ruleset with scopes

• update-ruleset — Update ruleset properties

• delete-ruleset — Remove a ruleset

• create-deny-rule — Create a deny rule (regular or override deny) in a ruleset

• update-deny-rule — Update an existing deny rule

• delete-deny-rule — Remove a deny rule

IP List Management

• get-iplists — Get IP lists with structured ip_ranges and fqdns, pversion draft|active, is_default on the Any list, and contains_ip for an exact server-side "which lists cover this address" lookup

• create-iplist — Create a new IP list

• update-iplist — Update an existing IP list

• delete-iplist — Remove an IP list

Service Management

• get-services — Get services with optional filtering by name, port, protocol, and max results

• create-service — Create a new service definition

• update-service — Update an existing service

• delete-service — Remove a service

Traffic Analysis

• get-traffic-flows — Get detailed traffic flow data with filtering by date range, source/destination, service, policy decision, and more

• get-traffic-flows-summary — Get aggregated traffic summaries grouped by app, env, port, and protocol

Automated Ringfencing

• create-ringfence — Automated app-to-app segmentation policy creation. Analyzes traffic flows to discover which remote apps communicate with a target app, then creates a ruleset with:

  • Intra-scope allow rule — all workloads within the app can communicate freely

  • Extra-scope allow rules — each discovered remote app gets an allow rule on All Services

  • Selective enforcement mode (selective=true) — adds a deny rule blocking all inbound, with allow rules for known apps processed first. Gets you to enforcement faster than full enforcement mode.

  • Deny consumer flavors (deny_consumer parameter):

    • any (default) — IP list Any (0.0.0.0/0) as consumer, deny only at destination. Safest.

    • ams — All Workloads as consumer, deny pushed to every managed workload. Broader.

    • ams_and_any — Both. Maximum coverage.

  • Policy coverage awareness — each rule is annotated as already_allowed (traffic covered by existing policy, created for documentation) or newly_allowed (filling a policy gap). Summary shows how many remote apps are already covered vs need new rules.

  • skip_allowed parameter — set to true to only create rules for traffic not yet covered by existing policy, producing minimal rulesets that fill gaps only

  • Merge-safe — detects existing rulesets and rules, never creates duplicates

  • Dry-run support — preview what would be created without making changes

Infrastructure Service Identification

• identify-infrastructure-services — Discover which apps are infrastructure services by analyzing traffic patterns. Builds an app-to-app communication graph and uses dual-pattern scoring to recognize two types of infrastructure:

  Provider infra (AD, DNS, shared DB) — consumed by many apps, high in-degree, low out-degree. Consumer infra (monitoring, backup, log shipping) — connects out to many apps, high out-degree, low in-degree.

  Two scores are computed per app, and the higher one wins:

  Score	Degree metric (40%)	Directionality (30%)	Betweenness (25%)	Volume (5%)
  Provider	In-degree	Consumer ratio (in/total)	Betweenness centrality	Connection volume
  Consumer	Out-degree	Producer ratio (out/total)	Betweenness centrality	Connection volume

  Mixed-traffic dampening: score *= 1 / (1 + min(in_degree, out_degree) * 0.3) — apps with both significant inbound AND outbound connections are business apps, not infrastructure. Pure directional apps (all in OR all out) get no penalty.

  Non-production environments (staging, dev, etc.) receive a 50% score penalty since infrastructure services typically live in production.

  Apps are classified into tiers:

  • Core Infrastructure (score >= 75) — monitoring, AD, SIEM, DNS. Policy these first.

  • Shared Service (score >= 50) — shared databases, message queues. Policy these second.

  • Standard Application (score < 50) — normal business apps.

  Each result includes a dominant_pattern field ("provider" or "consumer") indicating which type of infrastructure the app resembles.

  Why this matters: Infrastructure services are consumed by many apps OR connect out to many apps. If you ringfence apps without allowing infrastructure services first, you break dependencies. This tool tells you what to policy first.

Policy Lifecycle

• provision-policy — Provision pending draft changes to move them from draft to active state. Can provision all pending changes or specific items by href. Includes change descriptions for audit trail.

• compare-draft-active — Compare draft vs active policy to preview what would change on provisioning. Shows created, updated, and deleted rulesets, rules, IP lists, and services.

Enforcement Readiness

• enforcement-readiness — Assess whether an app is ready for enforcement. Analyzes traffic flows, existing policy coverage, enforcement modes, and ringfence status. Returns a readiness score (0-100) with actionable recommendations:

  • Policy coverage (40 points) — what percentage of traffic is covered by rules

  • Ringfence exists (20 points) — has a ringfence ruleset been created

  • Enforcement mode (20 points) — are workloads in full/selective/visibility_only

  • No blocked traffic (10 points) — no unintended blocks

  • All remote apps covered (10 points) — no uncovered remote app traffic

Batch Operations

• ringfence-batch — Ringfence multiple apps at once. Optionally uses identify-infrastructure-services to auto-order apps by infrastructure score (infrastructure first, then standard apps). Supports dry-run mode to preview all changes before applying.

Workload Enforcement Status

• get-workload-enforcement-status — Get enforcement mode status across workloads, grouped by app and environment. Shows counts per mode (idle, visibility_only, selective, full) and identifies apps with mixed enforcement states — a common issue during rollouts.

Policy Coverage

• get-policy-coverage-report — Generate a policy coverage report for an app showing what traffic is covered by existing rules vs what would be blocked. Breaks down by inbound/outbound, identifies uncovered services and remote apps, and provides an overall coverage percentage.

• find-unmanaged-traffic — Find traffic involving unmanaged workloads or IP addresses. These are sources/destinations without app/env labels, representing policy blind spots. Filters by direction (inbound/outbound/both) and connection count.

Security Analysis

• detect-lateral-movement-paths — Detect potential lateral movement paths by analyzing app-to-app traffic patterns. Identifies articulation points (bridge nodes) whose compromise would provide access to otherwise disconnected app groups. Computes reachability from any starting app and traces multi-hop paths up to a configurable depth.

• compliance-check — First look at policy posture against a framework (PCI-DSS, DORA, NIS2, NIST 800-53, CIS Controls, ISO 27001, SWIFT CSP, HIPAA, or general best practices). Keyword-routed heuristics on draft policy and recent traffic, summarised as a score with per-check findings (PASS/FAIL/WARNING). Not audit evidence.

• collect-compliance-evidence — Audit evidence for segmentation controls per app/env scope pair, from active policy and observed traffic: inventory, enforcement, VEN health, unmanaged workloads, described providing rules, no broad consumer, admitted services versus an approved list, inbound and outbound boundary crossings with a blocked-flow timeline, draft-versus-active drift, events and flows in the window. Per test and pair: PASS/FAIL/EXCEPTION/NOT_TESTED with the rule, the measured values and the rows. A capped pull never passes. Framework mapping lives in the illumio://compliance/* resources.

Event Monitoring

• get-events — Get PCE events with optional filtering by event type, severity, status, and result limits

Connection Testing

• check-pce-connection — Verify PCE connectivity and credentials

Testing

The project includes a comprehensive integration test suite that runs against a real PCE using the MCP protocol.

# Set up credentials in .env
cat > .env << EOF
PCE_HOST=your-pce-host
PCE_PORT=8443
PCE_ORG_ID=1
API_KEY=your-api-key
API_SECRET=your-api-secret
EOF

# Run all tests
uv run pytest tests/ -v

The test suite covers:

• Tool listing and schema validation

• Full CRUD lifecycle for workloads, labels, IP lists, services, rulesets, and deny rules

• Traffic flow queries and summaries

• Ringfence creation (standard, selective, deny consumer flavors, merge idempotency)

• Infrastructure service identification (scoring, sorting, tier classification)

• Error handling for missing resources

Illumio Rule Processing Order

Understanding rule processing is essential for ringfencing:

1. Essential rules — built-in, cannot be modified

2. Override Deny rules — block traffic overriding all allows (emergency use)

3. Allow rules — permit traffic (ringfence remote app rules go here)

4. Deny rules — block specific traffic (ringfence deny-all-inbound goes here)

5. Default action — selective mode = allow-all, full enforcement = deny-all

In selective enforcement, the default is allow-all, so a deny rule is needed to make the ringfence effective. Known remote apps get allow rules (step 3) which are processed before the deny (step 4).

Visual Examples

All the examples below were generated by Claude Desktop and with data obtained through this MCP server.

Application Analysis

Detailed view of application communication patterns and dependencies

Analysis of traffic patterns between different application tiers

Infrastructure Insights

Overview dashboard showing key infrastructure metrics and status

Detailed analysis of infrastructure service communications

Security Assessment

Comprehensive security analysis report

Security assessment findings for high-risk vulnerabilities

PCI compliance assessment findings

SWIFT compliance assessment findings

Remediation Planning

Overview of security remediation planning

Detailed steps for security remediation implementation

Policy Management

Management interface for IP lists

Overview of ruleset categories and organization

Configuration of application ruleset ordering

Workload Management

Detailed workload analysis and metrics

Identification and analysis of workload traffic patterns

Label Management

Organization of PCE labels by type and category

Service Analysis

Automatic inference of service roles based on traffic patterns

Analysis of top 5 traffic sources and destinations

Project Planning

Project implementation timeline and milestones

Available Prompts

Ringfence Application

The ringfence-application prompt helps create security policies to isolate and protect applications by controlling inbound and outbound traffic.

Required Arguments:

• application_name: Name of the application to ringfence

• application_environment: Environment of the application to ringfence

Features:

• Creates rules for inter-tier communication within the application

• Uses traffic flows to identify required external connections

• Implements inbound traffic restrictions based on source applications

• Creates outbound traffic rules for necessary external communications

• Handles both intra-scope (same app/env) and extra-scope (external) connections

• Creates separate rulesets for remote application connections

Analyze Application Traffic

The analyze-application-traffic prompt provides detailed analysis of application traffic patterns and connectivity.

Required Arguments:

• application_name: Name of the application to analyze

• application_environment: Environment of the application to analyze

Analysis Features:

• Orders traffic by inbound and outbound flows

• Groups by application/environment/role combinations

• Identifies relevant label types and patterns

• Displays results in a React component format

• Shows protocol and port information

• Attempts to identify known service patterns (e.g., Nagios on port 5666)

• Categorizes traffic into infrastructure and application types

• Determines internet exposure

• Displays Illumio role, application, and environment labels

How to use MCP prompts

Step1: Click "Attach from MCP" button in the interface

Step 2: Choose from installed MCP servers

Step 3: Fill in required prompt arguments:

Step 4: Click Submit to send the configured prompt

How prompts work

• The MCP server sends the configured prompt to Claude

• Claude receives context through the Model Context Protocol

• Allows specialized handling of Illumio-specific tasks

This workflow enables automated context sharing between Illumio systems and Claude for application traffic analysis and ringfencing tasks.

Docker

The application is available as a Docker container from the GitHub Container Registry.

Pull the container

docker pull ghcr.io/alexgoller/illumio-mcp-server:latest

You can also use a specific version by replacing latest with a version number:

docker pull ghcr.io/alexgoller/illumio-mcp-server:1.0.0

Run with Claude Desktop

To use the container with Claude Desktop, you'll need to:

1. Create an environment file (e.g. ~/.illumio-mcp.env) with your PCE credentials:

PCE_HOST=your-pce-host
PCE_PORT=your-pce-port
PCE_ORG_ID=1
API_KEY=your-api-key
API_SECRET=your-api-secret

2. Add the following configuration to your Claude Desktop config file:

On MacOS (~/Library/Application Support/Claude/claude_desktop_config.json):

{
    "mcpServers": {
        "illumio-mcp-docker": {
            "command": "docker",
            "args": [
                "run",
                "-i",
                "--init",
                "--rm",
                "-v",
                "/Users/YOUR_USERNAME/tmp:/var/log/illumio-mcp",
                "-e",
                "DOCKER_CONTAINER=true",
                "-e",
                "PYTHONWARNINGS=ignore",
                "--env-file",
                "/Users/YOUR_USERNAME/.illumio-mcp.env",
                "illumio-mcp:latest"
            ]
        }
    }
}

Make sure to:

• Replace YOUR_USERNAME with your actual username

• Create the log directory (e.g. ~/tmp)

• Adjust the paths according to your system

Run Standalone

You can also run the container directly:

docker run -i --init --rm \
  -v /path/to/logs:/var/log/illumio-mcp \
  -e DOCKER_CONTAINER=true \
  -e PYTHONWARNINGS=ignore \
  --env-file ~/.illumio-mcp.env \
  ghcr.io/alexgoller/illumio-mcp-server:latest

Docker Compose

For development or testing, you can use Docker Compose:

version: '3'
services:
  illumio-mcp:
    image: ghcr.io/alexgoller/illumio-mcp-server:latest
    init: true
    volumes:
      - ./logs:/var/log/illumio-mcp
    environment:
      - DOCKER_CONTAINER=true
      - PYTHONWARNINGS=ignore
    env_file:
      - ~/.illumio-mcp.env

Then run:

docker-compose up

Contributing

1. Fork the repository

2. Create a feature branch

3. Commit your changes

4. Push to the branch

5. Create a Pull Request

License

This project is licensed under the GPL-3.0 License. See the LICENSE file for details.

Support

For support, please create an issue.