# 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](https://gofastmcp.com). 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](https://mcp.checkpoint.com/). 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`](https://github.com/CheckPointSW/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](https://docs.astral.sh/uv/) (recommended) or pip
- No credentials needed — the backend is in-memory

### Install & Run

```bash
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

```json
{
  "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