marker-watch-mcp
# marker-watch-mcp
`marker-watch-mcp` is an MCP server for one long-running command. It watches
that command's output for a start and end marker, then saves the enclosed
output as a numbered build result.
Use it when another tool already reruns your build or check command. This
server does not watch files or restart processes.
## Install
Node.js 20+ and pnpm are required.
```sh
pnpm install
pnpm build
pnpm link -g
```
Ensure pnpm's global bin directory is on your `PATH`, then configure your MCP
client to run the linked command:
```json
{
"mcpServers": {
"marker-watch": {
"command": "marker-watch-mcp",
"args": [
"--cwd", "/absolute/path/to/project",
"--start-marker", "@@build:start@@",
"--end-marker", "@@build:end@@",
"--",
"your-watcher", "--", "your-check-command"
]
}
}
}
```
Everything after `--` is the command to run, with its arguments unchanged.
You can instead use `--command` and `--args`, or the corresponding
`MARKER_WATCH_MCP_*` environment variables. `--log-file /tmp/marker-watch.log`
keeps a raw output log.
## How it works
The command must stay running and write a start marker followed by an end
marker for each run. Markers match literal text in complete output lines after
terminal color codes are removed. The saved result keeps the original output.
The server keeps the latest 20 completed results. It exposes these MCP tools:
- `get_build_status` — current process and build state.
- `get_build` — a saved result; omit `version` for the latest.
- `await_build` — wait for the next result after a version.
- `start_build_wait` and `get_build_wait` — start and poll a non-blocking wait.
- `debug_get_live_output` — recent raw output for diagnosing a stuck run.
## Typical use
```text
get_build_status() -> latestCompletedVersion: 41
edit files -> your watcher runs the check
await_build({ afterVersion: 41 }) -> version 42 and its output
```
For a long check, call `start_build_wait({ afterVersion: 41 })` and poll the
returned ID with `get_build_wait`.
TDQS
Scored across 6 tools
Most tools have clearly distinct purposes: status, specific version result, blocking wait, non-blocking wait state, and debug output. The only mild ambiguity is between get_build_status, get_build_wait, and await_build, which all involve build state/results and require reading descriptions carefully.
The tool names consistently use snake_case and mostly follow a get_/await_/start_ verb pattern. The compound debug_get_live_output deviates slightly, and the repeated get_build_* prefix creates some similarity, but overall the naming is predictable and readable.
Six tools is a well-scoped size for a build-monitoring server. Each tool covers a distinct aspect of querying or waiting for build results without redundancy or bloat.
The surface covers the key workflows: checking overall status, fetching a specific build result, waiting for the next completed build, starting a non-blocking wait, polling that wait, and debugging unresponsive builds. No critical missing operation is apparent for the stated purpose.