What are MCP servers, really? The boot sequence nobody writes about.

MCP servers are long-lived OS processes that speak the Model Context Protocol (JSON-RPC 2.0 over stdio, SSE, or streamable HTTP) and expose a catalog of named tools an LLM can call. In practice, they are not abstract 'services' but real processes on your machine with startup sequences, memory, and lifecycle concerns. Terminator's MCP agent is a concrete example: a Rust binary that runs 150+ lines of boot hygiene (kill orphans, verify port 17373, install a panic hook, UTF-8 fix, start telemetry) before it accepts its first list_tools request.

Because MCP clients spawn MCP servers as child processes. When an editor like Claude Code or Cursor crashes, restarts, or loses its connection, the child MCP servers can be orphaned: still running, still holding ports, still hanging onto automation handles. Terminator's agent is especially prone to this because it holds OS-level UIAutomation resources. So main.rs line 151's kill_previous_mcp_instances function scans for other copies of terminator-mcp-agent and terminator-bridge-service, skips itself, and kills the rest. Default mode only kills processes whose parent is dead (so other active editors keep their agents). Pass --enforce-single-instance and it kills every other copy regardless.

Stdio MCP servers communicate by writing JSON-RPC 2.0 frames to stdout. Anything non-JSON on stdout breaks the protocol: the client sees malformed data and disconnects. The default Rust panic behavior writes to stdout. So Terminator installs a custom panic hook at main.rs line 270 that writes only to stderr, never to stdout. Every panic payload, every location line goes to stderr. This is one of those details that never appears in the MCP spec but is essential if you want your server to survive a single handler bug without killing the whole session.

Windows consoles default to code page IBM437, which mangles UTF-8 output. The accessibility tree from Windows UIA is full of unicode (app names, element properties), so Terminator forces the console to UTF-8 via cmd /c chcp 65001. It uses std::process::Command::spawn without waiting for completion because, per the code comment, on some Azure VMs chcp can take 6+ seconds and a blocking call would miss the health check window. So the fix is fire-and-forget. By the time any real work starts, the console is already UTF-8.

It turns the MCP server into an auto-destructing process. When you pass --watch-pid <parent_pid>, main.rs spawns a tokio task that calls is_process_alive(pid) every 1000ms (Windows-only, via PROCESS_QUERY_LIMITED_INFORMATION with a fallback to PROCESS_QUERY_INFORMATION). The moment that parent PID stops responding, the agent calls std::process::exit(0). This exists because editors can crash without cleaning up their children; --watch-pid ensures the MCP server doesn't linger after the editor it was spawned for is gone.

Depends on the server. The reference SDK servers are usually stdio only. Terminator's MCP agent supports three, selected by a --transport flag: Stdio (default, used by local editors), Sse (Server-Sent Events, for legacy web integrations), and Http (streamable HTTP, for remote clients and load-balanced deployments). The three have different lifecycles: stdio blocks on service.waiting(), SSE blocks on Ctrl+C then calls child_process::kill_all(), and HTTP uses a shared Arc<RwLock<Option<DesktopWrapper>>> so recorder state persists across requests. Same dispatch_tool, same tools, three wildly different process shapes.

There is no reserved port in the MCP spec. Servers pick whatever they want. Terminator's MCP agent defaults to 127.0.0.1:3000 for SSE and HTTP transports and uses 17373 for internal coordination (that's the port it verifies after cleanup). You can override host and port via --host and --port. If you're running multiple MCP servers behind a reverse proxy, you'll end up assigning them ports yourself anyway.

A REST API is usually stateless and designed to run behind a load balancer with N replicas. An MCP server on stdio is a single process owned by a single editor session, and its internal state (focus restoration, active recorders, in-progress workflows, cancellation tokens for long-running clicks) has to survive between tool calls. That's why an MCP server cares about boot hygiene in a way a REST API usually doesn't: one process per session, holding real OS resources, means you really don't want two copies fighting. Terminator's enforce_single_instance flag exists specifically for production deployments where exactly one agent per machine is required.

Three things on top of the tool extraction. It runs git rev-parse HEAD to capture the commit hash into GIT_HASH, git rev-parse --abbrev-ref HEAD for the branch into GIT_BRANCH, and chrono::Utc::now().to_rfc3339() for BUILD_TIMESTAMP. All three get injected via cargo:rustc-env so the final binary carries its own provenance. Every boot logs those three values along with the binary path, modification time, and file size. When a user reports a bug, you can ask 'what was the Git commit line in your startup logs?' and narrow the source revision instantly.

If you only ever use one AI editor on one machine and never restart it, you won't care. The moment you run Claude Code and Cursor at the same time, or restart your editor in the middle of an automation, or try to run Terminator in a CI pipeline or on a shared Windows VM, you'll hit every one of these concerns. The difference between an MCP server that 'works on my machine' and one that holds up in production is exactly this boot-hygiene layer: orphan cleanup, port retries, panic isolation, lifecycle flags. It isn't glamorous but it's the majority of the code that separates a demo from a product.