phpstan-mcp-mx 0.21.1 → 0.23.0

package/CHANGELOG.md

@@ -3,6 +3,25 @@
 All notable changes per version. Generated by semantic-release from the commit
 history since 0.10.0; the versions before that were written by hand.
 
+# [0.23.0](https://codeberg.org/MartijnSchimmel/phpstan-mcp-mx/compare/v0.22.0...v0.23.0) (2026-09-12)
+
+
+### Features
+
+* accept a project relative to the client's working directory ([e2025d9](https://codeberg.org/MartijnSchimmel/phpstan-mcp-mx/commit/e2025d990ef4a65658fe5db08f75249a450d0116))
+
+# [0.22.0](https://codeberg.org/MartijnSchimmel/phpstan-mcp-mx/compare/v0.21.1...v0.22.0) (2026-09-12)
+
+
+### Bug Fixes
+
+* start PHPStan without a detached console on Windows ([20cd44c](https://codeberg.org/MartijnSchimmel/phpstan-mcp-mx/commit/20cd44c260823a5fc06744c98a82411e5e0e51bc))
+
+
+### Features
+
+* wip ([0cc18dc](https://codeberg.org/MartijnSchimmel/phpstan-mcp-mx/commit/0cc18dc211d09c87b54efdaacc0667414e7c1df2))
+
 ## [0.21.1](https://codeberg.org/MartijnSchimmel/phpstan-mcp-mx/compare/v0.21.0...v0.21.1) (2026-09-11)
 
 
@@ -159,7 +178,7 @@ history since 0.10.0; the versions before that were written by hand.
 
 ## 0.8.0
 
-- Nieuwe tool `server_config`: met welke instellingen deze server draait — roots, standaard
+- Nieuwe tool `server_config`: met welke instellingen deze server draait roots, standaard
   geheugenlimiet, hoeveel analyses tegelijk, waar de tijdelijke bestanden heen gaan en of
   schrijvende tools aanstaan. Een geweigerde instelling wordt gemeld in plaats van
   verzwegen.

package/README.md

@@ -6,7 +6,7 @@ serves several PHP projects at once; you decide which ones.
 ## Installation
 
 The server runs as a separate process that your MCP client starts. Install it globally once
-and then register it with the client you use — Claude Code and Claude Desktop each keep their
+and then register it with the client you use Claude Code and Claude Desktop each keep their
 own list, so you do this separately for both.
 
 ```bash
@@ -14,11 +14,13 @@ npm install -g phpstan-mcp-mx
 ```
 
 Below, replace `/path/to/projects` everywhere with the directory that holds your PHP
-projects. It is required; see [Configuration](#configuration) for why.
+projects. In Claude Code you can also leave `PHPSTAN_MCP_ROOTS` out: the server then works in
+the directory the session runs in. See [Configuration](#configuration) for why there is always
+a limit.
 
 ### Claude Code
 
-With `--scope user` the server is available in all your projects — which is what you want
+With `--scope user` the server is available in all your projects which is what you want
 from one server that serves several projects.
 
 ```bash
@@ -53,7 +55,7 @@ phpstan:
 ```
 
 `claude mcp get` and `claude mcp list` actually connect to the server instead of just reading
-back the configuration — so they tell you whether it really starts. Inside a session, `/mcp`
+back the configuration so they tell you whether it really starts. Inside a session, `/mcp`
 does the same. Then ask for the project list: if it comes back empty while the connection is
 up, your roots point to the wrong directory and there is nothing wrong with the server
 itself.
@@ -82,7 +84,7 @@ If that file doesn't exist yet, create it yourself:
 ```
 
 If there already is an `mcpServers` block, add `phpstan` next to the existing entries instead
-of replacing the file — otherwise you overwrite the servers that are already in it.
+of replacing the file otherwise you overwrite the servers that are already in it.
 
 Desktop only reads that file at startup, and on macOS closing the window is not quitting:
 quit the app completely (⌘Q) and start it again. After that, `phpstan` shows up among the
@@ -102,7 +104,7 @@ If you get something like `env: node: No such file or directory`, or the server
 The `phpstan-mcp-mx` command is a script that starts with `#!/usr/bin/env node`, and `npx`
 is itself a command that has to be found. Both work in your terminal because your shell
 profile puts Node on `PATH`. But the MCP server is started by a *different* program, and that
-one does not always inherit your shell profile — a GUI app on macOS often gets only a bare
+one does not always inherit your shell profile a GUI app on macOS often gets only a bare
 `PATH` with `/usr/bin` and `/bin`. Node isn't there: Homebrew puts it in `/opt/homebrew/bin`,
 and nvm, fnm, asdf and volta somewhere under your home directory.
 
@@ -134,7 +136,7 @@ And for Claude Desktop:
 ```
 
 You can check whether `PATH` is the problem yourself, without involving the MCP client. The
-binary is looked up in your own shell first and then started with a bare `PATH` — otherwise
+binary is looked up in your own shell first and then started with a bare `PATH` otherwise
 the command itself can't be found and you are measuring something else:
 
 ```bash
@@ -154,10 +156,10 @@ echo '' | env -i PATH=/usr/bin:/bin \
 ```
 
 ```
-phpstan-mcp 0.20.0 listening on stdio, 0 root(s) configured, at most 2 at a time
+phpstan-mcp 0.23.0 listening on stdio, no roots configured, so the client's directories (MCP roots) are in scope, at most 2 at a time
 ```
 
-(Zero roots is correct here: `env -i` also throws away `PHPSTAN_MCP_ROOTS`. All that matters
+(No roots is correct here: `env -i` also throws away `PHPSTAN_MCP_ROOTS`. All that matters
 is *that* it starts.)
 
 ### Updating
@@ -207,6 +209,7 @@ path in `PHPSTAN_MCP_CONFIG`):
   "maxParallel": 2,
   "tmpDir": "project",
   "allowWrites": false,
+  "php": "/opt/homebrew/opt/php@8.4/bin/php",
   "runners": {
     "/Users/you/projects/admin": {
       "command": ["docker", "exec", "-w", "/var/www/html", "admin-app"],
@@ -223,13 +226,13 @@ That makes your MCP registration a single line without `--env`, and keeps the co
 in one place instead of spread over seven variables.
 
 A file that doesn't exist is not an error: then only the environment applies. A file that
-*does* exist but is invalid stops the server from starting — someone meant something there
+*does* exist but is invalid stops the server from starting someone meant something there
 that would otherwise silently not happen.
 
-### `PHPSTAN_MCP_ROOTS` (required)
+### `PHPSTAN_MCP_ROOTS` (recommended)
 
-`PHPSTAN_MCP_ROOTS` is required: a list of absolute paths, separated by a colon (a semicolon
-on Windows). Everything below them may be analysed, nothing outside them.
+`PHPSTAN_MCP_ROOTS` is a list of absolute paths, separated by a colon (a semicolon on
+Windows). Everything below them may be analysed, nothing outside them.
 
 ```
 PHPSTAN_MCP_ROOTS=/Users/you/projects:/Users/you/work/client-x
@@ -240,6 +243,25 @@ directories with a `composer.json`, stops as soon as it finds one, and skips `ve
 `node_modules/` and hidden directories. A layout like `~/projects/<client>/<project>` works
 with `~/projects` as the only root.
 
+Without `PHPSTAN_MCP_ROOTS`, the directories the client shares through MCP roots are the
+limit instead. Claude Code shares the directory the session runs in, so there the server
+reaches exactly the project you started it in. A client that shares no directories leaves
+nothing in reach: then the server refuses every project and says why. Set the variable when
+one server should reach several projects, or with such a client.
+
+### The client's directory and relative paths
+
+A `project` may also be relative: `.` is the directory the client shares, and `packages/api`
+starts from there. This uses MCP roots, not the directory the server process happens to run
+in a client that doesn't start the server in your project (Claude Desktop) would otherwise
+silently point `.` somewhere else. It needs exactly one shared directory: with none there is
+nothing to resolve against, and with several (Claude Code after `/add-dir`) it would be a
+guess; both are refused with a message asking for the full path.
+
+With `PHPSTAN_MCP_ROOTS` set, that list stays the limit: `.` then only works if the client's
+directory lies within it. `list_projects` and `server_config` show which list applies and
+what `.` resolves to.
+
 ### `PHPSTAN_MCP_MAX_PARALLEL` (optional)
 
 How many analyses may run at the same time, across projects. Two by default.
@@ -248,7 +270,7 @@ How many analyses may run at the same time, across projects. Two by default.
 PHPSTAN_MCP_MAX_PARALLEL=4
 ```
 
-Analyses within the same project always run in order — two simultaneous runs would overwrite
+Analyses within the same project always run in order two simultaneous runs would overwrite
 each other's result cache. This limit is about the machine as a whole: without it, a model
 that calls ten projects after `list_projects` starts ten PHPStan processes, each spinning up
 its own parallel workers. With `PHPSTAN_MCP_MEMORY_LIMIT=2G` that is ten times that ceiling.
@@ -272,7 +294,7 @@ Where PHPStan puts its temporary files, and therefore where the result cache end
 The default solves a silent problem. PHPStan's `tmpDir` defaults to
 `sys_get_temp_dir()/phpstan`, so *every* project without its own `tmpDir` in its config
 shares a single `resultCache.php`. Two projects in a row then invalidate each other's cache,
-and the cache — the reason a second analysis is fast — stops doing anything. Measured on two
+and the cache the reason a second analysis is fast stops doing anything. Measured on two
 real projects, with another project in between:
 
 ```
@@ -289,14 +311,36 @@ If you set `tmpDir` yourself in your `phpstan.neon`, that wins: a configuration
 explicitly takes precedence over what this server provides.
 
 Choose `shared` if you want the server to use the same cache as your terminal, or if setting
-`TMPDIR` disturbs something in your project — with Larastan, an entire Laravel application
+`TMPDIR` disturbs something in your project with Larastan, an entire Laravel application
 runs in the same process.
 
+### `PHPSTAN_MCP_PHP` (optional; needed on Windows unless `php.exe` is on your PATH)
+
+The PHP binary that starts PHPStan on the host, as an absolute path:
+
+```
+PHPSTAN_MCP_PHP=C:\Users\you\.config\herd\bin\php85\php.exe
+```
+
+`vendor/bin/phpstan` is a PHP script with a `#!/usr/bin/env php` line. macOS and Linux start
+that by themselves; Windows does not. On Windows the server therefore starts
+`php.exe vendor/bin/phpstan …`, just like Composer's own `phpstan.bat` does, but without a
+shell in between. It looks for `php.exe` on your `PATH`; if it can't find one, every analysis
+of a project without a runner fails with a message that points here.
+
+Herd puts a `php.bat` on your `PATH` and not a `php.exe`. A batch file can't be started
+without a shell, so it doesn't count: point this setting at the `php.exe` inside Herd's
+`bin\php85` (or whichever version you use) instead. A `.bat` or `.cmd` here is rejected with
+that explanation.
+
+On macOS and Linux you can use it to pick a specific PHP version; without it, the script's
+own `#!/usr/bin/env php` decides. `server_config` shows which PHP is used.
+
 ### `PHPSTAN_MCP_RUNNERS` (optional)
 
 Some projects cannot be analysed on the host. Larastan really boots your Laravel
 application, and if the host lacks, say, `ext-redis`, the bootstrap fails and the analysis
-stops — while the same repository runs fine inside its container.
+stops while the same repository runs fine inside its container.
 
 With this variable you say, per project, where PHPStan should run:
 
@@ -329,17 +373,18 @@ this is something a human sets once: a model only picks a project, and whether a
 environment belongs to it is already decided. If a caller could pass in the command, the
 caller would decide what gets executed and the whitelist would be pointless.
 
-### Why that list is required
+### Why there is always a list
 
 PHPStan is not a passive parser. It loads the project's autoloader, executes
 `bootstrapFiles` from the configuration and loads extensions as PHP code. "Analyse directory
-X" therefore means "execute the PHP code that X's configuration points to" — and the path
+X" therefore means "execute the PHP code that X's configuration points to" and the path
 comes from a language model. The list of roots makes what is in reach explicit and decided
-by a human.
+outside the model: by a human in `PHPSTAN_MCP_ROOTS`, or by the client that shares the
+directory it was started in. Neither can come from a tool call.
 
 ### `PHPSTAN_MCP_MEMORY_LIMIT` (optional)
 
-If PHPStan runs into the PHP memory limit, a call can pass `memoryLimit` — but only after
+If PHPStan runs into the PHP memory limit, a call can pass `memoryLimit` but only after
 the analysis has already failed. With this variable you set the default once, next to your
 roots:
 
@@ -358,12 +403,12 @@ alternative is `memory_limit` in your `php.ini`, which then applies to *every* P
 your machine.
 
 If one project needs more than the rest, set it for that project in `PHPSTAN_MCP_PROJECTS`
-instead of raising this value for everyone — with `PHPSTAN_MCP_MAX_PARALLEL=2`, a
+instead of raising this value for everyone with `PHPSTAN_MCP_MAX_PARALLEL=2`, a
 machine-wide 4G is two times 4G.
 
 ### `PHPSTAN_MCP_PROJECTS` (optional)
 
-Defaults for a single project, as JSON — or under `projects` in the config file:
+Defaults for a single project, as JSON or under `projects` in the config file:
 
 ```json
 {
@@ -390,25 +435,29 @@ of the project: for the notice that a baseline is included and for `unmatched_ig
 
 An unknown key is rejected, not ignored: `memorylimit` with a lowercase l would otherwise
 silently do nothing. `list_projects` and `server_config` show which defaults apply, and a
-broken value is listed there as a problem — the project list keeps working.
+broken value is listed there as a problem the project list keeps working.
 
 ## Tools
 
-Every tool expects an explicit `project` path. The server has no "current project": that
-would be state the model doesn't see in its context, with the wrong project silently
-analysed as a result.
+Every tool expects an explicit `project`: an absolute path, or a path relative to the
+directory the client shares (`.` for that directory itself, see
+[above](#the-clients-directory-and-relative-paths)). The server keeps no "current project"
+between calls: that would be state the model doesn't see in its context, with the wrong
+project silently analysed as a result. The model names the project in every call, and every
+answer names its full path.
 
 ### `list_projects`
 
 Lists the projects that are in reach, with for each project whether PHPStan is installed and
-which config file it has. Start here — the `path` from the result is what the other tools
-expect as `project`.
+which config file it has. Start here the `path` from the result is what the other tools
+expect as `project`. It also says where the list comes from (`rootsFrom`: `PHPSTAN_MCP_ROOTS`
+or the client) and what `.` resolves to (`workingDirectory`).
 
 ### `analyse_project`
 
 | Argument | Required | Meaning |
 | --- | --- | --- |
-| `project` | yes | absolute path to the project root |
+| `project` | yes | path to the project root, absolute or relative to the client's directory |
 | `paths` | no | paths inside the project; empty means: follow `phpstan.neon` |
 | `level` | no | level override, `0` to `10` or `max` |
 | `config` | no | a different config file, e.g. `phpstan-strict.neon`; must lie inside the project |
@@ -432,18 +481,18 @@ not match `argumentx.something`).
 
 ### `analyse_file`
 
-Same arguments, plus a required `path` — a single file or directory inside the project. The
+Same arguments, plus a required `path` a single file or directory inside the project. The
 path may be relative to the project root or absolute, but it has to lie inside it.
 
 ### `analyse_changed`
 
 Analyses the PHP files that git considers changed. Meant for checking whether your own
-change introduces errors, without analysing the whole project — and without the response
+change introduces errors, without analysing the whole project and without the response
 filling up with what has been there for years.
 
 | Argument | Required | Meaning |
 | --- | --- | --- |
-| `project` | yes | absolute path to the project root |
+| `project` | yes | path to the project root, absolute or relative to the client's directory |
 | `base` | no | commit, branch or tag to compare against (`HEAD` by default) |
 | `staged` | no | only what is staged (`git diff --cached`), for a check before a commit |
 | `onlyChangedLines` | no | only findings on lines that were changed |
@@ -455,7 +504,7 @@ the whole branch instead of just your uncommitted work.
 Each finding says with `onChangedLine` whether it is on a changed line; in the text it is
 prefixed with a `+`. A changed file often also contains errors that were already there, and
 without that distinction you either start fixing those or stop too early. Keep in mind: a
-finding on an unchanged line can still follow from your change — a modified signature causes
+finding on an unchanged line can still follow from your change a modified signature causes
 errors at the call sites, and you didn't touch those lines.
 
 Those call sites are often in files you didn't change at all, and then this tool doesn't even
@@ -471,15 +520,15 @@ src/Use.php  (not changed)
      4  arguments.count  Function greet invoked with 1 parameter, 2 required.
 ```
 
-PHPStan then analyses the `paths` from your config. A changed file outside them — a test in a
-project that only analyses `src` — isn't covered by that, and the response names it; leave out
+PHPStan then analyses the `paths` from your config. A changed file outside them a test in a
+project that only analyses `src` isn't covered by that, and the response names it; leave out
 `scope` to analyse the changed files themselves.
 
-That is slower — with a warm result cache one to five seconds on real projects, depending on
-how many files depend on what you changed — and every old error in the project shows up under
+That is slower with a warm result cache one to five seconds on real projects, depending on
+how many files depend on what you changed and every old error in the project shows up under
 "not changed" too. **With exactly one changed file, the server therefore also analyses the
-project as it was before your change** — that one file replaced by its version at `base`, via
-PHPStan's editor mode — and compares the two:
+project as it was before your change** that one file replaced by its version at `base`, via
+PHPStan's editor mode and compares the two:
 
 ```
 Compared with the project before your change (src/Lib.php at HEAD): 0 fixed, 1 new, 3 still open.
@@ -489,18 +538,18 @@ New:
 
 On a real project, adding a required parameter to a method called in four other files gave
 exactly those four calls as new, and the 25 findings that were already there as still open.
-That costs a second run. With more than one changed file it can't be done — editor mode
-replaces one file per run — and then one analysis cannot tell which findings your change
+That costs a second run. With more than one changed file it can't be done editor mode
+replaces one file per run and then one analysis cannot tell which findings your change
 caused; a finding that names what you changed is the strongest hint, and after a fix
 `compareTo` tells exactly what is new. A `compareTo` you pass yourself takes precedence.
 
 Two things it includes that are easy to miss: **new files not yet added to git** (`git diff`
 doesn't know them, so there is a second query for them) and **nothing from
-`resources/views`** — a `.blade.php` ends in `.php`, but it is a template that PHPStan never
+`resources/views`** a `.blade.php` ends in `.php`, but it is a template that PHPStan never
 sees in a normal run, because the config doesn't list that directory in `paths`.
 
 Every path git reports goes through the same check as a path the model supplies itself.
-Whatever doesn't pass — a broken symlink, a file pointing outside the project — is listed as
+Whatever doesn't pass a broken symlink, a file pointing outside the project is listed as
 "skipped" in the response instead of silently dropping out.
 
 If the project is not under git, the tool says so and points to `analyse_project` with
@@ -508,20 +557,20 @@ explicit `paths`.
 
 **What the change hides** is listed under "Note": new
 `@phpstan-ignore` comments (with file, line, identifier and reason) and ignored errors added
-to a baseline that is included — even if no PHP file changed otherwise. An ignore whose reason
+to a baseline that is included even if no PHP file changed otherwise. An ignore whose reason
 is the only thing that changed does not count as new. The notice doesn't pass judgement: an
 ignore can be justified, the point is that it doesn't happen silently. Ignored errors that
 disappeared from the baseline are listed too.
 
 ### `inspect_type`
 
-Shows the type PHPStan infers for one or more expressions at a given line — what you need
+Shows the type PHPStan infers for one or more expressions at a given line what you need
 before fixing a type error, and exactly what PHPStan's own guidance asks you not to override
 with a cast, `assert()` or an inline `@var`.
 
 | Argument | Required | Meaning |
 | --- | --- | --- |
-| `project` | yes | absolute path to the project root |
+| `project` | yes | path to the project root, absolute or relative to the client's directory |
 | `path` | yes | one PHP file inside the project |
 | `line` | yes | the types are those right before this line runs |
 | `expressions` | yes | 1 to 10 PHP expressions, e.g. `["$user", "$request->input('id')"]` |
@@ -537,7 +586,7 @@ Types right before line 37 of src/Actions/Contract/BuildContractRowsAction.php:
 ```
 
 The project is not changed. The server inserts `\PHPStan\dumpType(<expression>);` before
-`line` in a temporary copy of the file — one line per expression — and has PHPStan read that
+`line` in a temporary copy of the file one line per expression and has PHPStan read that
 copy in place of the original (PHPStan's editor mode, `--tmp-file` and `--instead-of`). The
 copy lives in the server's temp directory, or with `PHPSTAN_MCP_RUNNERS` in the temp
 directory of that environment, like the config of `unmatched_ignores`. Only that one file is
@@ -545,7 +594,7 @@ analysed, so it also works for a file outside the `paths` of your config and doe
 warm result cache; on a real project it took one to two seconds.
 
 `line` has to be the first line of a statement inside a function or method. Anywhere else —
-in the middle of an array literal that spans several lines, directly in a class body — the
+in the middle of an array literal that spans several lines, directly in a class body the
 inserted line breaks the file, and you get PHPStan's parse errors back instead of types, with
 the line numbers of your original file. A file under `excludePaths` fails with the reason
 `nothing_to_analyse`. Editor mode needs a recent PHPStan; an older one fails with a message
@@ -562,7 +611,7 @@ phpstan-mcp 0.20.0
 
 Project directories:
   /Users/you/projects
-  /does/not/exist  — does not exist
+  /does/not/exist  does not exist
 
 Memory limit:        2G
 Parallel:            2
@@ -574,7 +623,7 @@ Per-project defaults (a tool argument takes precedence):
   /Users/you/projects/shop: memory 4G, timeout 900s
 ```
 
-Until now that information was only in the startup line on stderr — visible in your client
+Until now that information was only in the startup line on stderr visible in your client
 log, invisible to the model. A rejected setting is reported instead of omitted: if
 `PHPSTAN_MCP_MAX_PARALLEL` is set to nonsense, that field is `null` and the reason appears
 under "Rejected settings", while the rest stays readable.
@@ -611,7 +660,7 @@ directory is the one `clear_result_cache` clears. If the application doesn't boo
 without the extensions the app needs), this part is missing, with the reason stated.
 
 Last come the Composer scripts that run PHPStan, and how they differ from the way this server
-runs it — the reason a developer can see different results than the server does:
+runs it the reason a developer can see different results than the server does:
 
 ```
 Composer scripts that run PHPStan:
@@ -623,7 +672,7 @@ Composer scripts that run PHPStan:
 ```
 
 If a framework is installed whose magic PHPStan can't see without an extension, and that
-extension isn't loaded, that comes first — it explains more than anything else:
+extension isn't loaded, that comes first it explains more than anything else:
 
 ```
 Missing PHPStan extensions:
@@ -636,7 +685,7 @@ they are in nearly every project, often as a dependency of a dependency, and a n
 project is noise. What is loaded comes from PHPStan's own diagnosis, so an extension included by
 hand counts too.
 
-Scripts are recognised by their command, not their name, and are only read — never run. A
+Scripts are recognised by their command, not their name, and are only read never run. A
 script that goes through `make` or another script can't be read without running it, so it is
 left out. Only what changes the result is compared: the config, the memory limit, the level,
 explicit paths and `--autoload-file`. The server never takes these over by itself: that would
@@ -645,7 +694,7 @@ let the project decide how the server starts PHPStan.
 ### `clear_result_cache`
 
 Clears PHPStan's result cache, so the next analysis recomputes everything. Useful when a
-result doesn't match the code — for example after a change to an extension or an included
+result doesn't match the code for example after a change to an extension or an included
 config.
 
 By default that cache does **not** live in the project but in the system temp directory
@@ -667,22 +716,22 @@ Reads a project's `phpstan-baseline*.neon` and counts what is being ignored, per
 and per file. Does not run an analysis, so the answer is immediate.
 
 Note the distinction: what is in here is exactly what `analyse_project` does *not* report. A
-project that includes its baseline only reports the errors that are new — PHPStan already
+project that includes its baseline only reports the errors that are new PHPStan already
 makes that comparison itself.
 
-It also counts the inline `@phpstan-ignore` comments in the code — the third place where
+It also counts the inline `@phpstan-ignore` comments in the code the third place where
 errors get hidden, next to the baseline and `ignoreErrors` in the config, and the only one
 nothing counted until now:
 
 ```
-18 inline @phpstan-ignore comment(s) in 14 file(s) — counted in all PHP files git knows, also outside the analysed paths. These are hidden too, and a new baseline does not touch them.
+18 inline @phpstan-ignore comment(s) in 14 file(s) counted in all PHP files git knows, also outside the analysed paths. These are hidden too, and a new baseline does not touch them.
 11 have no identifier (@phpstan-ignore-line, -next-line): they ignore every error on their line.
 1 name an identifier but give no reason in parentheses.
 ```
 
 That is counted with `git grep`, so `vendor/`, ignored files and Blade templates stay out,
 and files not yet added to git count. Without git, the baseline part still works and the
-response says why the inline comments were not counted — `null`, not zero, because zero
+response says why the inline comments were not counted `null`, not zero, because zero
 would claim nothing is hidden.
 
 With `path` (e.g. `"app/Models/User.php"`) you also get the entries for that one file: per
@@ -693,12 +742,12 @@ it is precisely a deleted file that the entries doing nothing belong to.
 
 Finds the ignore rules that no longer do anything: baseline entries for errors that were
 fixed long ago, and entries whose `count` is higher than what still occurs. Many projects set
-`reportUnmatchedIgnoredErrors: false`, and then this grows unnoticed — on one project, 554 of
+`reportUnmatchedIgnoredErrors: false`, and then this grows unnoticed on one project, 554 of
 the 2116 baseline entries turned out to match nothing any more.
 
 | Argument | Required | Meaning |
 | --- | --- | --- |
-| `project` | yes | absolute path to the project root |
+| `project` | yes | path to the project root, absolute or relative to the client's directory |
 | `memoryLimit` | no | this is a full analysis, so it may need more |
 | `timeoutSeconds` | no | 300 by default |
 | `offset` / `limit` | no | which part of the entries you get back |
@@ -717,7 +766,7 @@ different, and with only part of the project, everything outside it looks stale.
 
 With an execution environment (`PHPSTAN_MCP_RUNNERS`) the temporary config goes into the
 temporary directory of *that* environment (`${TMPDIR:-/tmp}` inside the container), because a
-container can't see the host's temporary directory — only the project directory is mounted.
+container can't see the host's temporary directory only the project directory is mounted.
 That needs a `sh` in the environment; without one, the tool says so with the reason
 `unsupported_with_runner`. PHPStan can't read its config from stdin, so there is no way
 around writing a small file somewhere; it is never written into the project itself.
@@ -725,7 +774,7 @@ around writing a small file somewhere; it is never written into the project itse
 ### `generate_baseline` (only with write access)
 
 Puts all current errors into a baseline, so that the next analysis only reports what is new.
-Meant for bringing an existing project under PHPStan — not for making errors go away.
+Meant for bringing an existing project under PHPStan not for making errors go away.
 
 This tool only exists if the server was started with `PHPSTAN_MCP_ALLOW_WRITES=1`:
 
@@ -736,12 +785,12 @@ claude mcp add phpstan --scope user \
   -- phpstan-mcp-mx
 ```
 
-Without that variable it isn't registered — so it doesn't appear in the tool list at all,
+Without that variable it isn't registered so it doesn't appear in the tool list at all,
 rather than existing and refusing every call. All other tools stay read-only.
 
 | Argument | Required | Meaning |
 | --- | --- | --- |
-| `project` | yes | absolute path to the project root |
+| `project` | yes | path to the project root, absolute or relative to the client's directory |
 | `file` | no | target file inside the project (`phpstan-baseline.neon` by default) |
 | `allowEmpty` | no | write even if there is nothing to ignore |
 
@@ -764,23 +813,23 @@ Workflows that only combine existing tools. A prompt rather than a tool, because
 context in every session and a prompt only when you pick it. Every guardrail in the texts
 comes from a trial run on a real project that went wrong without that sentence.
 
-- **`phpstan_review_change`** — review your own change with
+- **`phpstan_review_change`** review your own change with
   `analyse_changed`, start with the findings on changed lines, and repeat until it is clean
   (without `runId`, otherwise you see the result from before your fix). With `base` (e.g.
   `main`) for a whole branch before a PR.
-- **`phpstan_raise_level`** — what one level higher costs: two counts
+- **`phpstan_raise_level`** what one level higher costs: two counts
   with `limit: 1` and the difference per kind. The level is often set in a shared config in
   `vendor/`, and `ignore.*` findings don't count: those are inline `@phpstan-ignore` comments
   that have nothing to ignore on a different level.
-- **`phpstan_shrink_baseline`** — what in the baseline is stale
+- **`phpstan_shrink_baseline`** what in the baseline is stale
   (`unmatched_ignores`), what a new baseline would hide (`analyse_project`), and the cheapest
   real reduction. Cleaning up and hiding stay two separate things: `generate_baseline` is only
   suggested when there is nothing to hide, and never called on its own initiative.
-- **`phpstan_fix_identifier`** — a clean-up round for one identifier or a
+- **`phpstan_fix_identifier`** a clean-up round for one identifier or a
   group such as `missingType`, with the `runId` within the round and without `runId` after
   every fix. Without `identifier` the model picks a kind: first what can be fixed at the
   source, otherwise a kind that sits in one or two files.
-- **`phpstan_compare_projects`** — two projects side by side
+- **`phpstan_compare_projects`** two projects side by side
   (`diagnose_project`, level, baseline, runners and defaults), showing only the differences.
   If no difference explains the behaviour, a stale result cache is the next suspect.
 
@@ -846,7 +895,7 @@ Same message more than once (one fix may cover several; check that they point to
 ```
 
 On one real project, the top two lines pointed to the same method signature: 8 of its 25
-findings. Messages are compared exactly, without normalising names or numbers away — and a
+findings. Messages are compared exactly, without normalising names or numbers away and a
 generic message such as `Possibly invalid array key type mixed.` can still have separate
 causes, so it is a pointer, not a promise.
 
@@ -859,7 +908,7 @@ then comes from this result instead of a new analysis.
 
 With that `runId`, the next page comes from the same result. Without it, every page would be a
 new analysis, and if you change a file in between you get pages with different totals. Only
-`offset`, `limit`, `identifiers`, `onlyIn` and `onlyChangedLines` may differ — so one analysis
+`offset`, `limit`, `identifiers`, `onlyIn` and `onlyChangedLines` may differ so one analysis
 of the whole project can be read directory by directory without running PHPStan again. If the `runId` belongs to
 different arguments, has expired (after ten minutes) or is unknown, a new analysis follows
 with a notice instead of an error.
@@ -887,7 +936,7 @@ note that which one it is cannot be told apart.
 
 The comparison counts over all findings, not just the page, and only needs the same arguments
 as the earlier analysis (`offset`, `limit` and `identifiers` may differ). With
-`analyse_changed`, a file that only one of the two analyses covered is not compared — touch a
+`analyse_changed`, a file that only one of the two analyses covered is not compared touch a
 second file while fixing, and its existing errors would otherwise show up as new. Those are
 counted separately. A `runId` stays usable for comparing for an hour, longer than for paging:
 the fixing itself sits between the two analyses.
@@ -904,7 +953,7 @@ PHPStan can return valid JSON and at the same time say on stderr that it didn't
 goes at the very top of the response, before anything else:
 
 ```
-WARNING — PHPStan reported this alongside the result:
+WARNING PHPStan reported this alongside the result:
 - Result is incomplete because of severe errors.
 ```
 
@@ -921,7 +970,7 @@ Note:
 ```
 
 That is the difference between "no findings" and "no findings, plus a thousand that aren't
-reported". The check looks at whether your config really includes the file — a baseline
+reported". The check looks at whether your config really includes the file a baseline
 sitting next to `phpstan.neon` without being included does nothing.
 
 PHPStan's own guidance for reading findings is kept separately in `instructions` and shown
@@ -934,7 +983,7 @@ PHPStan adds:
 ```
 
 That block is the same every run and says nothing about *this* analysis, so it doesn't count
-as a warning — and it isn't truncated, because half a block of guidance helps nobody.
+as a warning and it isn't truncated, because half a block of guidance helps nobody.
 
 The `warnings` field is separate from `generalErrors`: the latter is PHPStan's own `errors`
 array from the JSON. Both lists are capped at ten messages of at most 1000 characters each —
@@ -952,10 +1001,10 @@ How many were left out is in `omitted`, and in the text as "N more message(s) no
 - **The PHP memory limit.** PHPStan easily exceeds it on a large project;
   `memoryLimit: "1G"` usually solves that. The crash comes back as a regular error, with
   PHPStan's own explanation attached.
-- **Larastan boots your Laravel application.** If that fails — missing `.env`, database not
-  reachable — the analysis fails with Larastan's own explanation.
+- **Larastan boots your Laravel application.** If that fails missing `.env`, database not
+  reachable the analysis fails with Larastan's own explanation.
 - **Analyses in the same project run one after another,** because they share one result cache
-  (per project, in the temp directory — not in the project itself). Different projects do run
+  (per project, in the temp directory not in the project itself). Different projects do run
   in parallel.
 - **A stale result cache** can make PHPStan crash with a message that seems to make no sense.
   After a `composer update` that no longer happens, because the cache directory follows

package/dist/baseline.d.ts

@@ -100,7 +100,7 @@ export interface BaselineFileEntry {
  *
  * Nodig omdat de samenvatting per soort en per bestand apart telt: welke soorten in
  * wélk bestand zitten, stond alleen in het baseline-bestand zelf. Het pad wordt alleen
- * vergeleken, niet geopend — het hoeft dus niet te bestaan, en dat is goed: een baseline
+ * vergeleken, niet geopend het hoeft dus niet te bestaan, en dat is goed: een baseline
  * noemt soms een bestand dat al weg is.
  */
 export declare function baselineEntriesFor(project: ResolvedProject, path: string): BaselineFileEntry[];