The Problem with Plugins

The initial setup treated the Message Communication Protocol (MCP) server as a plugin within the agent process. This architecture proved brittle. When the agent's core process, OpenCode, restarted, it took down the MCP server too, because they shared the same execution space. This led to unexpected downtime and, crucially, data loss. The Windows agent went silent mid-session, routing tasks through ark-delegator, a cross-environment bridge in WSL. The MCP server behind it, registered as a plugin, crashed with OpenCode's daemon restart. The same process, the same failure, the same data loss.

A quick check of the process table revealed the core issue. While ark-memory (on port 8102) and ark-exec (on 8101) were running, and all other MCP servers managed by systemd were alive, the agent's plugin-based MCP server was dead. Plugins, by design, live inside the agent's process. MCP servers, when managed independently, are robust. This incident was the catalyst for rethinking the MCP server's role: they are not plugins, but independent services.

Diagram showing a brittle plugin-based MCP architecture vs. a robust independent service architecture

The Refactored Stack: Independent MCP Servers

The refactored architecture treats MCP servers as standalone, supervised services. The `oh-my-mcp` service, managed by systemd as a user service, is the orchestrator. It exposes two key ports:

  • Port 8080: Management API: This endpoint allows for direct interaction with the MCP server for configuration, status checks, and management tasks.
  • Port 8090: Gateway (MCP Proxy): This acts as the primary ingress point for agent communications, routing messages to the appropriate backend MCP services.

Crucially, `oh-my-mcp` supervises its child processes. This means if an individual MCP server or its associated task handler crashes, `oh-my-mcp` can detect it and restart it automatically, ensuring resilience and minimizing downtime. This supervisory layer is key to maintaining dynamic workflows. The agent itself becomes a client of these independent MCP services, rather than being coupled to their lifecycle.

Leveraging the CLI for Dynamic Workflows

The Command Line Interface (CLI) is the linchpin for dynamically managing and interacting with these independent MCP services. Instead of relying on a monolithic agent or complex inter-process communication within a single process, the CLI provides a clean, scriptable interface.

Consider a scenario where an AI agent needs to perform a series of complex tasks. These tasks might involve interacting with different tools, accessing various data sources, or even coordinating with other agents. The CLI allows for the construction of these workflows:

  • Task Orchestration: The CLI can be used to chain commands, where the output of one MCP-mediated task becomes the input for the next. For example, an agent might use the CLI to request a data retrieval task from MCP service A, then pass the retrieved data to MCP service B for analysis, and finally use MCP service C to generate a report.
  • Dynamic Service Discovery and Routing: As MCP services are started, stopped, or scaled, the gateway (port 8090) can dynamically update its routing table. The CLI can query the Management API (port 8080) to understand the current state of available services and their endpoints, enabling intelligent routing of tasks.
  • Configuration Management: The CLI can be used to push configuration updates to individual MCP services or to the gateway itself, allowing for runtime adjustments to workflow behavior without restarting the entire system. This is invaluable for A/B testing different routing strategies or adjusting resource allocation.
  • Monitoring and Debugging: The CLI provides immediate access to logs, status endpoints, and health checks of individual MCP services. This granular visibility is essential for quickly diagnosing and resolving issues in complex, distributed AI agent systems.

This CLI-driven approach transforms the MCP infrastructure from a static backend into a flexible, programmable fabric. It allows for the creation of highly dynamic AI agent workflows where agents can adapt their behavior and resource utilization in real-time based on task demands and system conditions.

Real-World Application: Multi-Agent Coordination

In a multi-agent system, agents often need to collaborate. One agent might be responsible for user interaction, another for data processing, and a third for action execution. Without a robust communication layer, coordinating these agents becomes a significant challenge.

Using independent MCP servers with CLI management offers a solution:

  • Agent A (User Interaction): Receives a user query. It uses the CLI to send a structured request to an MCP service dedicated to query understanding.
  • MCP Service (Query Understanding): Processes the query, identifies the necessary information, and routes a request to an MCP service for data retrieval.
  • MCP Service (Data Retrieval): Fetches the required data and returns it.
  • MCP Service (Action Execution): Agent A, via the CLI, then instructs this service to perform an action based on the retrieved data. This service might interact with external APIs or databases.
  • Agent A (Response Generation): Finally, Agent A uses the CLI to query an MCP service for response generation, synthesizing the results into a coherent answer for the user.

Each step is an independent service call, managed and orchestrated via the CLI. The `oh-my-mcp` system ensures that these services are always available and resilient. If the data retrieval service temporarily fails, `oh-my-mcp` will restart it, and the CLI can be configured to retry the operation. This distributed, microservice-like approach to AI agent communication provides scalability and fault tolerance far beyond what a monolithic plugin architecture could offer.

Beyond Plugins: A Robust Foundation

The shift from treating MCP servers as plugins to independent, supervised services managed via systemd and orchestrated by a powerful CLI is fundamental. It addresses the core fragility of tightly coupled architectures. This approach provides:

  • Resilience: Independent services are easier to monitor, restart, and isolate. Systemd handles the heavy lifting of process supervision.
  • Scalability: Individual MCP services can be scaled independently based on demand, rather than scaling the entire agent.
  • Maintainability: The codebase for each MCP service can be simpler and focused on a single responsibility.
  • Flexibility: Dynamic workflows can be constructed and modified on the fly using the CLI, adapting to changing requirements.

This architecture is not just about avoiding crashes; it's about building a robust, adaptable foundation for complex AI agent systems. By separating concerns and leveraging standard process management tools alongside a powerful CLI, developers can build more reliable and dynamic AI workflows.