phpgraph

phpgraph

A knowledge graph of your PHP codebase, for AI coding agents.

Static analysis served over MCP to Sherpa , Claude Code, Codex, Cursor and any MCP client.

No LLM, no network, no embeddings: deterministic facts, each with a confidence level.

English · Français

---

Why phpgraph?

An AI agent dropped into an unfamiliar PHP project reads files one by one and greps for names. It misses what matters most in a real codebase: who calls what, which handler receives a message, which controller serves a route, what breaks if a method changes, and which layer depends on which.

phpgraph parses the whole project once (with nikic/php-parser, docblocks with phpstan/phpdoc-parser) and answers those questions from a graph:

• Deterministic facts, not guesses. Every relation is EXTRACTED (read in the code), INFERRED (resolved from declared types) or AMBIGUOUS (a guess, labelled as such).
• It says what it does not know. Unresolved calls, missing vendor/, messages without handlers: the gaps are reported, so the agent knows when to read the code itself.
• Built for DDD and hexagonal architecture, then microservices, then PHP in general: Symfony, Laravel, Ecotone, PrestaShop, WordPress, or plain PHP.
• Private by design. Your code never leaves your machine, and phpgraph never executes it: it only parses it.

Features

• Call graph with type inference: return types, chained calls ($a->b()->c()), local variables, docblocks (@return, @var), and signatures of your vendor/ dependencies, so chains go through Doctrine, Symfony or Laravel APIs.
• Architecture: DDD and hexagonal layers, bounded contexts, layer rules checked in CI (phpgraph check), and impact analysis (impact_of): what depends on a class or method, and which tests to run.
• Messages and events: sender → message → handler for Symfony Messenger, Laravel jobs and events, Ecotone, PrestaShop CQRS, WordPress hooks, domain events and your own buses, from attributes, service configuration (YAML, XML, PHP) or code shape.
• HTTP: routes (Symfony attributes, YAML and PHP routing files, API Platform resources, Laravel route files, controllers named by container service id) linked to controllers, and HTTP calls linked to the routes they reach. A route whose controller class exists neither in the project nor in vendor/ is reported with its routing file.
• Dependency injection: what the Symfony container configuration injects beyond constructor types, every service of a tag (tagged_iterator, #[AutowireIterator]) or a service named by id, from PHP, YAML or XML configuration, including helpers called with literal arguments (Wiring::wire($services, 'sales', ...), evaluated, never run): a validator is linked to the rules it receives. A rule declaring what it accepts (supports(object $input): bool { return $input instanceof CreateEstimateQuery; }, also canHandle, accepts…) is kept out of the use cases passing another input to the shared pipeline, the classes the input's properties hold included. An input typed by an interface is any project class implementing it and the parameter types it is passed on to (QueryInterface $query given to setUp(CreateEstimateQueryInterface $query): a CreateEstimateQuery); a guard it cannot read, or a rule running for some of these classes only, is kept, marked supports() not resolved.
• Microservices: one id space per service, and links between services through their contracts: shared message classes, routing keys, HTTP routes.
• API schemas: the operations of OpenAPI (Swagger) documents linked to the routes implementing them, or, for a document of another API, to the HTTP calls of its client; the rpcs of protobuf services linked to the classes implementing their generated interface. What is documented and not implemented, and the routes no document describes, are reported. impact lists the operations behind a change (the contract its clients rely on), outline those a feature serves.
• Zero-configuration MCP server: built on first use, rebuilt incrementally when the code changes (about 3 s per edit on an 8,400-file project).

Quick start

1. Install. A single executable, no PHP needed (Linux and macOS on x86_64 and ARM, Windows on x86_64):

curl -fsSL https://raw.githubusercontent.com/hbenabdallah/phpgraph/main/install.sh | sh                  # latest release

curl -fsSL https://raw.githubusercontent.com/hbenabdallah/phpgraph/main/install.sh | sh -s -- 0.2.0 # a given release curl -fsSL https://raw.githubusercontent.com/hbenabdallah/phpgraph/main/install.sh | sh -s -- dev-main # the main branch

irm https://raw.githubusercontent.com/hbenabdallah/phpgraph/main/install.ps1 | iex                       # Windows

$env:PHPGRAPH_VERSION = "dev-main"; irm https://raw.githubusercontent.com/hbenabdallah/phpgraph/main/install.ps1 | iex

The script downloads the binary, checks its SHA-256 and puts it in ~/.local/bin (Windows: %LOCALAPPDATA%\Programs\phpgraph, added to the PATH); PHPGRAPH_INSTALL_DIR changes the directory. Run it again to update. dev-main is rebuilt on every push to main (the edge pre-release). The binary is a static PHP runtime with phpgraph inside, built with static-php-cli.

With PHP 8.5+ installed, or with Docker:

composer require --dev hbenabdallah/phpgraph       # or: composer global require hbenabdallah/phpgraph

curl -LO https://github.com/hbenabdallah/phpgraph/releases/latest/download/phpgraph.phar docker pull ghcr.io/hbenabdallah/phpgraph # nothing else to install

2. Connect your agent. mcp-config prints a ready-to-paste configuration with the paths filled in (vendor/bin/phpgraph when installed with Composer):

phpgraph mcp-config sherpa    # Sherpa: a `sherpa mcp add` command, one declaration for every project

phpgraph mcp-config claude # Claude Code: a claude mcp add command, or .mcp.json phpgraph mcp-config codex # Codex: ~/.codex/config.toml phpgraph mcp-config cursor # Cursor: .cursor/mcp.json, shareable with the team phpgraph mcp-config json # any other MCP client over stdio

Agents reach for grep first, even with phpgraph connected. mcp-config also prints a line for the instructions file of the project (CLAUDE.md, AGENTS.md) telling the agent to call phpgraph before grep or reading files; the MCP instructions of the server say it too.

With Sherpa, a terminal coding agent, one declaration serves every project: Sherpa starts its MCP servers from the project it runs in.

sherpa mcp add phpgraph -- ~/.local/bin/phpgraph serve

In a Sherpa session, /mcp add does the same, and the tools are there at once. Both write ~/.config/sherpa/mcp.json.

With Claude Code (absolute paths, as mcp-config prints them):

claude mcp add phpgraph -- /home/you/.local/bin/phpgraph serve /path/to/project

3. Ask your agent something like *"Give me an overview of this project"*, *"How does an order get placed?"* or *"What breaks if I change OrderRepository::save?"*. The graph is built on the first call, then kept up to date.

MCP tools

The server tells the agent to call overview first. A path, as an agent sees it, on php-ddd-example:

Shortest path (4 hops):

PUT /courses/{id} --handled_by--> CoursesPutController::__invoke() --dispatches--> CreateCourseCommand --handled_by--> CreateCourseCommandHandler::invoke() --calls--> CourseCreator::invoke()

Command line

phpgraph build [path]