The MCP server that compiles your desktop workflow
before it clicks a single pixel.

It takes a workflow_path argument, checks that the path exists and contains a tsconfig.json, then shells out to the TypeScript compiler with `tsc --noEmit` in that directory. It tries `bun tsc --noEmit` first because bun has a faster cold start; if bun is not on PATH it falls back to `npx tsc --noEmit`; if npx is not on PATH it falls back to a global `tsc`. The implementation is at crates/terminator-mcp-agent/src/tools/typecheck.rs lines 142-204. The tool is registered as an MCP tool in crates/terminator-mcp-agent/src/server.rs at lines 9521-9545 with the description "Type-check a TypeScript workflow using tsc --noEmit. Returns structured error information including file, line, column, error code, and message for each type error found."

Each line of tsc stdout/stderr is matched against the regex `^(.+?)\((\d+),(\d+)\):\s*error\s+(TS\d+):\s*(.+)$` in typecheck.rs line 54. The five capture groups map to file path, 1-indexed line, 1-indexed column, the TS error code, and the message. There are two unit tests in the same file at lines 210-228: `test_parse_tsc_output_single_error` verifies a single TS2345 error parses correctly, and `test_parse_tsc_output_multiple_errors` verifies two errors on two lines both parse. Both are the first things that run on every CI build of the MCP agent.

After the parser produces a list of TypeError structs, enrich_errors_with_context walks each one, reads the corresponding source file, and builds a block of 7 lines: the 3 lines before the failing line, the failing line itself, and the 3 lines after. The failing line is prefixed with the literal string " -> " and all other lines with 4 spaces. Each line includes its 1-indexed line number, right-aligned in a 4-character field. The logic is at typecheck.rs lines 90-115. The practical effect is that when the LLM reads the tool response, it sees the broken code in its original shape, not a paraphrase, and can edit the file directly.

Both. The MCP tool typecheck_workflow exists so agents can call it explicitly. The CLI runs the same check automatically whenever you point `terminator mcp run` at a TypeScript workflow. The detection lives in crates/terminator-cli/src/typescript_workflow.rs `is_typescript_workflow` at lines 7-60: a `.ts` or `.js` file, or a directory containing package.json plus one of terminator.ts, src/terminator.ts, workflow.ts, or index.ts. If detected, `run_type_check` at lines 154-249 runs tsc and, on failure, prints a bordered error block with a literal hint: "Fix type errors before running the workflow. Or use --skip-type-check to bypass (not recommended)." You can bypass by passing `--skip-type-check` but the flag description in crates/terminator-cli/src/main.rs line 146 says exactly "Skip TypeScript type checking before execution (not recommended)."

Four accepted locations, in priority order: `terminator.ts` at the project root, then `src/terminator.ts`, then `workflow.ts`, then `index.ts`. The logic is in typescript_workflow.rs at `path_to_file_url` (lines 63-90). `terminator init` scaffolds `src/terminator.ts`, which becomes `file:///absolute/path/src/terminator.ts` as the workflow URL. That URL is what the state persistence layer hashes to derive the per-workflow state directory under `mediar/workflows/<folder>/state.json`.

`terminator init my-workflow` creates a directory with package.json (depends on `@mediar-ai/workflow` at latest, devDeps on typescript ^5 and @types/node ^20), a strict tsconfig.json (target ES2020, module commonjs, strict: true, esModuleInterop, rootDir ./src, outDir ./dist), a src/terminator.ts calling `createWorkflow` with a zod input schema and a list of step imports, and two example step files under src/steps/. The package.json's only script is `"build": "tsc --noEmit"`, which is the exact command the MCP server shells out to when typecheck_workflow runs. The implementation is in crates/terminator-cli/src/commands/init.rs lines 69-120.

Most MCP automation servers expose click, type, and screenshot primitives and let the LLM stitch them together inside the context window. If the LLM gets a selector wrong, you find out when the click misfires on a real window. Terminator's MCP server moves validation left: you author the workflow as a strongly-typed TypeScript module, the selectors and step return types are part of the TS signature, and both the MCP surface and the CLI refuse to run until `tsc --noEmit` passes. The LLM gets a structured error payload it can act on directly instead of a generic runtime exception, and the same check runs in CI without any divergence.

execute_sequence accepts YAML, JSON, and TypeScript workflows. The pre-execution type check only fires for TypeScript projects, because `is_typescript_workflow` in typescript_workflow.rs only returns true when it sees a TS entry file or a package.json + TS-entry combination. A YAML workflow takes the original path through the execute_sequence engine unchanged. If you want type-level safety on a YAML workflow, the documented pattern is to generate the YAML from a TypeScript file using `createWorkflow` and the zod schemas.