marker-watch-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MARKER_WATCH_MCP_CWD | No | Working directory for the command. Defaults to the current directory if not set. | |
| MARKER_WATCH_MCP_ARGS | No | Arguments to pass to the command. Use a JSON-encoded array or space-separated string as appropriate. | |
| MARKER_WATCH_MCP_COMMAND | Yes | The command to run and watch for markers. Equivalent to the first argument after `--`. | |
| MARKER_WATCH_MCP_LOG_FILE | No | Optional path to write a raw output log. | |
| MARKER_WATCH_MCP_END_MARKER | Yes | Literal end marker expected in a complete output line. | |
| MARKER_WATCH_MCP_START_MARKER | Yes | Literal start marker expected in a complete output line. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_build_statusB | Return the build process state and latest completed version. |
| get_buildC | Return the build result of the specified version. |
| await_buildC | Await the build result of the first completed version after afterVersion. |
| start_build_waitC | Start a non-blocking wait for the first completed version after afterVersion. |
| get_build_waitC | Return the state or final result of a non-blocking build wait. |
| debug_get_live_outputA | Return recent raw stdout and stderr from build processes. Meant only for debugging stuck builds. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.