Down the Rabbit Hole: Orchestrating Rust Development with a Custom MCP Server (mop_mcp)

Recently, the software engineering world was introduced to the Model Context Protocol (MCP)—an open standard designed to connect AI assistants to external datasets and tools, effectively acting as a "USB-C for AI." While the broader community has quickly built standard connectors for generic services like Google Drive or GitHub, I needed something far more specialized and powerful for the mop_dev ecosystem. I needed an AI co-pilot that didn't just passively read data, but actively managed my complex Rust build pipelines, navigated cross-platform compilation, and orchestrated zero-downtime deployments without breaking my environment.

Enter mop_mcp: a completely custom, highly optimized Model Context Protocol server built entirely in Rust. It serves as the definitive bridge between my IDE-based AI coding assistants and the underlying mop_dev infrastructure.

1. Taming the AI: The Sequential Command Queue

When you give an LLM raw terminal access, the workflow often degrades rapidly. AI agents tend to run overlapping commands, pollute standard output streams, and trip over file locks. mop_mcp solves this fundamental chaos by routing all AI intentions through a strict, sequential command queue.

• Execution Isolation: To protect the JSON-RPC communication channel, all spawned commands strictly use Stdio::null() for their standard streams, entirely preventing server crashes caused by stdio inheritance.
• Smart Timing & Recompile Detection: The server utilizes a custom SQLite timing database that tracks the duration of all historical commands. It maintains separate Exponential Moving Averages (EMA) for cached builds versus full recompiles by intelligently detecting the "Compiling" string in the cargo output. This allows the AI to see a highly accurate Estimated Time of Arrival (ETA) for queued jobs.

2. A Comprehensive Suite of Agentic Tools

To overcome the natural LLM bias toward using generic, error-prone terminal commands, I completely rewrote the tool names, descriptions, and trigger keywords. Now, the AI interacts with a curated API of high-level intentions:

• Knowledge Base Access: The kb_read, kb_list, and kb_search tools grant the agent semantic access to the workspace's markdown documentation. These endpoints are security-hardened to strictly prevent directory traversal and limit access exclusively to .md files.
• Deployment Simulation: Before an AI can touch production, it must run simulate_deploy. This tool automatically resolves the active project path and strictly enforces cargo fmt, cargo clippy, and cargo test --workspace. If the simulation passes, the deploy tool executes the full Git add, commit, and push sequence.
• Dev Server Management: A complete suite of commands (devserver_start, devserver_stop, devserver_logs, etc.) allows the AI to manage local development servers via cargo watch -x run. This is pre-configured for the entire MOP ecosystem, explicitly mapping ports to specific applications (e.g., mop_tasks on 3002, womed_it on 3001).
• Database & Network: The AI is empowered to execute secure queries against both local and production PostgreSQL databases via SSH (secure_production_database_query). It also utilizes an http_request tool equipped with sophisticated HTML parsing capabilities—extracting text, JSON, links, or specific CSS selectors using the underlying scraper and reqwest crates.
• E2E Testing: End-to-end testing is fully integrated via the cypress_run tool. To bypass shell layer instability (like MSVC environment pollution), it directly spawns node.exe and streams the full test output to the web UI console.

3. Navigating the Cross-Platform Labyrinth

The mop_dev infrastructure demands compiled binaries for Linux, macOS, and Windows. The mop_mcp server seamlessly bridges my Windows host machine and a dedicated WSL 2 (Debian-Rust-Dev) environment.

• Explicit Boundaries: Tools are explicitly suffixed (e.g., build_native_crate versus build_wsl_crate) to prevent the AI from confusing the host OS with the Linux subsystem.
• WSL File System Rules: The AI operates under strict instructions to never access /mnt/c/ for source code to avoid severe I/O performance penalties; all cloning and building happens natively inside the Linux filesystem at /home/dev/projects/....
• Cross-Compilation Magic: Using a custom Justfile, the AI can effortlessly orchestrate cross-compilation. Executing just build-mac-universal leverages the cargo-zigbuild toolchain to compile both x86_64-apple-darwin and aarch64-apple-darwin release binaries simultaneously, entirely bypassing the need for physical Apple hardware.
• Automated Release Packaging: A robust Makefile handles the final packaging of multi-OS releases, generating native executables and pairing them with the correct launcher.bat or launcher.sh scripts in a dedicated release/ directory.

4. The Human Window: The Web Dashboard

While the AI works autonomously in the background via the MCP stdio protocol, I require absolute visibility into its operations. To achieve this, mop_mcp hosts a real-time web dashboard running on port 3847.

• Split Console: To reduce cognitive overload and noise, the console output is divided into three persistent sub-tabs: General (for standard build and test outputs), Network (for HTTP requests), and Dev Servers (for live log streaming from the local environment).
• Unified Audit Log: Every single tool invocation—even lightweight queries like kb_read or devserver_list—is recorded in a unified audit trail with a 200-entry history cap. This provides a complete, transparent view of the AI's thought process and actions.
• Self-Development Capabilities: The server is entirely self-maintaining. The AI can utilize tools like mcp_build_server and mcp_restart_server to hot-reload its own codebase via the mcp_proxy shadow-copy supervisor, eliminating the need to manually restart the IDE.
• Micro-Footprint: Despite orchestrating the entire workspace, the infrastructure is incredibly lightweight. The primary mcp_build_checker_worker process consumes merely 3.3 MB of RAM, while the mcp_proxy supervisor sips a minuscule 0.1 MB.

mop_mcp is far more than a utility script; it is a foundational shift in how I interact with my codebase. By mapping complex operational invariants into strongly typed MCP tools, I've successfully transformed my LLM from a passive code generator into an active, context-aware site reliability engineer.