phpgraph

[phpgraph turns a PHP codebase into a knowledge graph of domains, handlers, repositories, controllers and adapters, served to AI agents through a CLI and an MCP server]

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.

[CI] [Packagist version] [Downloads] [PHP 8.5+] [License: MIT] [Listed on mcpservers.org]

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 releasecurl -fsSL https://raw.githubusercontent.com/hbenabdallah/phpgraph/main/install.sh | sh -s -- 0.2.0     # a given releasecurl -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/phpgraphcurl -LO https://github.com/hbenabdallah/phpgraph/releases/latest/download/phpgraph.phardocker 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 projectphpgraph mcp-config claude    # Claude Code: a `claude mcp add` command, or .mcp.jsonphpgraph mcp-config codex     # Codex: ~/.codex/config.tomlphpgraph mcp-config cursor    # Cursor: .cursor/mcp.json, shareable with the teamphpgraph 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]                        # phpgraph-out/graph.json and GRAPH_REPORT.mdphpgraph overview                            # stack, structure and gapsphpgraph impact "OrderRepository::save"      # what depends on it, and the tests to run (--all, --section tests, --format json)phpgraph check                               # layer rules, for CI: exit code 1 on a new violationphpgraph explain "PlaceOrderHandler"         # a node and its relations (-d in|out)phpgraph path "StockChecker" "DbalOrderRepository"phpgraph query "how is stock checked"phpgraph outline "notification validation"   # the outline of a feature (--section flow, --format json)phpgraph serve [path]                        # the MCP server, over stdiophpgraph mcp-config claude|codex|cursor|json [--docker image]

build options: -e to exclude paths (repeatable), --no-vendor not to read dependencies, --no-cache to parse every file again. vendor, node_modules, var, .git and the files ignored by the project's own .gitignore files are skipped; a git repository above the project never applies its rules, so a project copied into an ignored directory is still read. When the directory holds PHP files but every one is excluded, build fails and says so, and every MCP answer starts with that warning instead of serving an empty graph. Memory is unlimited by default; PHPGRAPH_MEMORY_LIMIT=2G sets a limit. The files are parsed by one worker process per processor, with PHP's pcntl extension (in the binaries and the Docker image; not on Windows, where they are parsed one after the other): Sylius builds in 10 s instead of 28 s on a 12-thread laptop. PHPGRAPH_WORKERS=4 sets the number of workers, PHPGRAPH_WORKERS=1 parses in one process. With PHP installed, opcache and its JIT make builds about 20% faster: php -d opcache.enable_cli=1 -d opcache.jit=tracing -d opcache.jit_buffer_size=128M vendor/bin/phpgraph build (the Docker image and the commands printed by mcp-config already use them).

What the graph contains

Every relation carries a confidence level:

phpgraph check --generate-baseline   # accept today's violations in phpgraph-baseline.jsonphpgraph check                       # fail on new ones only

rules:  dependencies:                       # who may depend on what    - name: doctrine-in-infrastructure      dependency: 'Doctrine\'      allow-from: ['App\*\Infrastructure\']  # or deny-from, which wins      reason: Only infrastructure talks to the database.  structure:                          # what the classes a pattern selects must be    - on: 'App\**\Controller\*'      not-on: 'App\Legacy\**'      target: class                   # class, interface, trait or enum      must-be-final: true             # must-be-abstract, must-be-readonly: true or false      must-be-named: '*Controller'      must-implement: ['App\Shared\Http\Controller']   # must-extend, must-use-trait      only-public-methods: [__construct, __invoke]  handlers:                           # a message handler dispatches the messages of its own bounded context    own-context: true    shared: [Shared]                  # contexts any handler may use

services:  - services/billing  - services/shipping

actions:  - file: Framework/jacActions.xml    element: //action                                 # XPath of the action elements    code: code                                        # their attributes (these are the defaults)    controller: controller    method: method    controller_file: '{dir}/control/{name}CTRL.php'   # _Stock/Reservation → _Stock/control/ReservationCTRL.php    target: target                                    # the action or template it goes on to    forward: { element: forward, result: result, target: target }    cited_in: [html, js]                              # the screens quoting the codes

Measured on real projects

phpgraph is developed against a corpus of open-source projects pinned to a commit, and every change is judged on their numbers (composer corpus:measure). Application code only; receiver typed is the share of method calls whose receiver type phpgraph could determine. Builds measured by corpus:measure, one project at a time, in Docker (PHP 8.5, no opcache), version 1.5.8.

Four microservices projects complete the corpus: two Laravel services over RabbitMQ, linked by 4 message contracts; four Laravel services over HTTP, where phpgraph found a POST sent to a GET-only route; Spiral's ticket booking, services calling each other through gRPC services declared in .proto files; and StayHub, seven Laravel services behind an API gateway described by an OpenAPI file. The last two measure API schemas as contracts: all 45 operations of StayHub's document and all 14 rpcs of ticket-booking are linked to what implements them. Zero parse failures on about 26,500 files. The details per project, including messages, routes and services, are in corpus/RESULTS.md.

With an agent

Measured on a private 4,800-file Symfony/DDD project, 3 runs per setup, the same agent (Sherpa) with and without phpgraph 1.0.2:

The ranges of the runs with and without phpgraph do not overlap.

Compared with other code graphs

Kimai 2.70.2 (Symfony, 1,072 source and 761 test files, not in the corpus phpgraph is measured on), October 2026, without any LLM: phpgraph 1.5.2 and graphify 0.9.93 (extract --code-only), on the same machine, in Docker. graphify keeps one edge per caller and callee, so calls between methods of the project are compared by pair; samples of the differences were checked in the code. tools/graphify/benchmark.sh runs it again.

• The pairs found by phpgraph only are resolved from declared types, inherited methods and instanceof included: 14 of 14 checked right. graphify misses calls on local variables and chains even when the method name is unique ($sut->hasUser(), $this->getDateTimeFactory()->getStartOfMonth()).
• Of graphify's 356 pairs, 243 link a call phpgraph links to another method of the same name: phpgraph is right on 11 of 12 checked, graphify on the twelfth (phpgraph follows the declared return type, AbstractWidgetType, to the inherited method; the object is a subclass overriding it). The 113 others: 11 of 12 checked wrong, calls on another object linked to the method of the same name in the current class (Doctrine's $em->rollback() to TimesheetRepository::rollback()); the twelfth is right, a call on a helper without a return type, which phpgraph counts as an unknown receiver.
• phpgraph's one miss among the 2,408 files: $user->isFirstDayOfWeekSunday() on what loadUserByIdentifier() declares to return, Symfony's UserInterface, which has no such method.
• What graphify has and phpgraph has not: other languages (Kimai's JavaScript), communities, an interactive visualisation and documents in the graph.

Sylius (the corpus commit), October 2026, without any LLM: phpgraph 1.0.2, codebase-memory-mcp 0.11.0 and graphify 0.9.76 (--code-only), on the same machine, in Docker. The calls were compared site by site (file, line, method), and samples of the differences were checked in the code.

• codebase-memory-mcp agrees with phpgraph on 99.7 % of the calls it resolves from types. The rest of its edges are guessed from the method name (confidence 0.04 to 0.44): where both link the same call, they disagree on 9,400 sites, and its 11,300 extra edges are mostly calls into vendor/ attached to a project method of the same name (19 of 20 checked).
• graphify links $this->other->foo() to foo() of the current class: right for $this->foo(), wrong for the 10 of 10 differences checked.
• What codebase-memory-mcp has and phpgraph has not: other languages, full-text and vector search, Cypher queries.

FAQ

Does phpgraph send my code anywhere? No. It runs locally, makes no network call and uses no LLM.

Does it execute my code? No. It parses PHP files and reads JSON, YAML and XML configuration. Even autoload_classmap.php and PHP service configurators are parsed, not included.

Which PHP versions can it analyse? Anything nikic/php-parser 5 parses: PHP 7 and 8 syntax, and the PHP 4 and 5 syntax removed since ($s{0}, =& new, octals like 08), for a file the newest grammar rejects. phpgraph itself needs PHP 8.5 or newer.

Which agents does it work with? Any MCP client over stdio: Sherpa, Claude Code, Codex, Cursor, Claude Desktop, and others. mcp-config prints the configuration for the common ones.

How large a project can it handle? The largest project of the corpus, Akeneo, has 8,400 files: about 22 s and 730 MB for a full build (in Docker, without opcache), about 3 s for a rebuild after an edit.

Limitations

• Only PHP is read: overview names the other languages of a mixed repository (their calls to the PHP part are not linked), and the MCP instructions say at once when a project has no PHP at all.
• Calls to global functions are not edges of the graph, though what a function returns types the calls on it (now()->addDay(), response()->json()); dynamic calls ($this->$name(), __call) are resolved only through the methods a class documents (@method, @mixin).
• Docblocks are read by phpstan/phpdoc-parser: a type may be written over several lines, a tag may follow another on the same line of a one-line docblock, and the forms older code writes though PHPDoc does not allow them are read as they mean (callable(Foo $x) without a return type, ?A|B, @method static NAME(): Type). Generics are read from docblocks (@template, @extends Repository<Order>, @return Collection<int, Item>, ScalarNodeDefinition<$this>), in the project and in vendor/: a template is bound by the type of the receiver and the parents passing it on, and a foreach walks the elements of any typed collection. A union (Response|ResponseFactory) or an intersection (Countable&Named), documented or declared, is called on every member declaring the method; a closure passed to a method gets the parameters the method documents it passes (@param callable($this): mixed, Laravel's when(fn ($query) => ...)); @use HasFactory<HotelFactory> on a trait use binds its templates. A template of a method is bound by the arguments of each call: the class an argument names (getRepository(Order::class) with @param class-string<T>), the type of a value (@param T $value), what a closure returns (@param callable(): T, its return statements or native type). @phpstan-return and @psalm-return are read before @return; a condition the arguments do not decide (TAsync is false ? Response : PromiseInterface) gives the union of its branches. Magic properties documented with @property and @property-read carry chains on; on an Eloquent model, so do the casts ('paid_at' => 'datetime' is a Carbon, an enum, the TGet of a cast class), the timestamps and the relations read as properties ($page->book, what book()->getResults() returns). A method declaring no return type returns what the method it overrides declares (@inheritDoc). A global $wpdb has the class the function's @global wpdb $wpdb gives; without the tag, it stays unknown. Conditions on a type ($id is array ? Collection : Model) are not evaluated, and a facade method documented as mixed (DB::transaction()) stays unknown.
• Local variables follow the branches of a function: where if/elseif/else, switch, match, try/catch, a ternary, ?? or a loop meet, a variable holds what any branch reaching that point assigned (one ending in return, throw, exit, break or continue does not reach it, null and scalars add nothing). instanceof, is_a(), assert(), &&/|| and match (true) narrow a variable where they hold, a negated test followed by an exit (if (!$x instanceof Foo) { return; }) narrows the code after it. A call on such a variable is linked to the method of each class it may hold: INFERRED when every branch typed it, AMBIGUOUS when one left it of unknown type. A call narrows its arguments as its callable documents it, in the project or in vendor/: @phpstan-assert, @psalm-assert and their -if-true/-if-false forms, a template bound by a class-string argument included (WordPress's is_wp_error(), Webmozart\Assert\Assert::isInstanceOf($x, Order::class), PHPUnit's assertInstanceOf()); only calls named like an assertion are looked up (is…, assert…, ensure…, check…, expect…, validate…, verify…, any static method of an …Assert or …Assertion class). Only variables are narrowed, not properties ($this->x instanceof Foo), and a loop body is read once (a type assigned at its end is not seen at its start).
• What a library makes of a call its signatures do not say comes from its provider (src/Builder/Libraries): a PSR-11 container asked for a class gives an instance of it ($container->get(Mailer::class)), an Eloquent model's attributes have the types of their casts, timestamps and relations.
• Chains stop at magic methods and at dependencies without a usable return type. PHP's own classes (DateTime, ArrayObject, SplObjectStorage, PDO...) are known from signatures generated once (tools/internal-classes.php); those of the intl and mysqli extensions are not.
• Without an installed vendor/, call chains stop at the first dependency.
• Services built at runtime (compiler passes, bundle extensions, ids computed from values only known at runtime), XML routes (but action files mapped in phpgraph.yaml), API Platform resources declared in XML or YAML, and API schemas other than OpenAPI and protobuf (GraphQL, AsyncAPI) are not read; an OpenAPI path rewritten by a gateway is not followed; injections that cannot be linked are listed by overview.
• Two services declaring a message class of the same name are assumed to share it.

Contributing

Issues and pull requests are welcome. See CONTRIBUTING.md: composer check must pass (php-cs-fixer, PHPStan level max, PHPUnit), and changes to the analysis are judged on the corpus. Without PHP installed, bin/dev composer check runs everything in Docker.

What stays stable across versions (commands, MCP tools, the graph.json format) is listed in docs/STABILITY.md; changes are in the changelog.

Releases are published by pushing a version tag: the release workflow builds the PHAR, the executables for Linux, macOS and Windows (tools/build-binary.sh), and the Docker image ghcr.io/hbenabdallah/phpgraph.

License

phpgraph is open source under the MIT License: you may use, copy, modify, merge, publish, distribute, sublicense and sell it, for any purpose, as long as the copyright notice and the license text are kept with it.