Check Point Management MCP Server

An MCP (Model Context Protocol) server for Check Point Management write-path workflows: draft an access rule, publish the session, install policy — the full compensating-control lifecycle, exposed as typed MCP tools with the same three-stage state machine as the real Management API.

Built with FastMCP v3. Originally built for a live orchestration demo at Tenable EXPOSURE 2026 (Boston), where an AI agent deployed a compensating firewall control for an unpatchable industrial asset under human supervision.

Why this exists

Check Point ships an official MCP server bundle. Its @chkp/quantum-management-mcp is the right read-side wrapper but is read-only by design — list rules, show objects, query topology, no writes. Compensating-control workflows (block traffic to an asset you can't patch yet) need add-access-rule, publish, and install-policy: an operator-supervised write path the official MCP intentionally doesn't expose.

This server fills that write-side gap with the three-stage lifecycle (draft → published → installed) matching the real Management API state machine — so an AI agent's audit trail reads exactly like a human operator's.

What it does (and doesn't)

Does: expose the write-path contract — tool signatures, rule lifecycle, response shapes — mirroring Check Point's Management API (add-access-rule, publish, install-policy, show-access-rulebase).

Doesn't (yet): contact a real Smart-1 or Security Management Server. The backend is in-memory, which makes it safe for demos, agent development, and workflow testing out of the box. For production, the in-memory backend swaps for the official cp_mgmt_api_python_sdk talking to Smart-1 Cloud or on-prem — tool signatures and response shapes do not change.

Tools

Tool	Lifecycle stage	Description
`checkpoint_list_access_rules`	read	List current rules in an access layer
`checkpoint_add_access_rule`	draft	Add a rule in the current session (status: `draft` until published)
`checkpoint_publish_session`	draft → published	Commit drafted rules to the management server
`checkpoint_install_policy`	published → installed	Push published rules to gateways — the rule actually enforces

The deliberate two-gate publish/install split mirrors real Check Point operator workflow, giving a supervising human two natural checkpoints before anything enforces.

Quick Start

Prerequisites

Python 3.11+
uv (recommended) or pip
No credentials needed — the backend is in-memory

Install & Run

git clone <repo-url> && cd checkpoint-mcp-server
uv sync
uv run checkpoint-mcp           # stdio mode for Claude Desktop / Claude Code
uv run pytest -v                # tests

Claude Desktop Integration

{
  "mcpServers": {
    "checkpoint": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/checkpoint-mcp-server", "checkpoint-mcp"]
    }
  }
}

Outputs

All tools return Markdown: rule tables with UID, source/destination/service/action, lifecycle status badges, and publish/install task summaries — shaped for LLM consumption and human-readable audit trails.

Stack

Python 3.11+, FastMCP v3, pydantic-settings, hatchling
Entry point: checkpoint_mcp.server:main (CLI: checkpoint-mcp)
In-memory state machine in state.py; vendor-shaped mock seed data in mock/data.py

Limitations

In-memory backend: no real Check Point management server is contacted; state resets on restart. Production use requires swapping in the official SDK (interfaces are designed for it).
Access-control scope only: NAT rules, threat prevention, VPN, and object management are not covered.
Single session model: no concurrent session/locking semantics like a real multi-admin Management Server.

License

MIT