Split Developer MCP: Enhancing Shell & Edit Tools

Hey guys! Let's dive into an exciting development within the Goose project. Currently, the developer MCP (Multi-Capability Provider) is like a Swiss Army knife, packed with various tools. But, as we all know, sometimes it's better to have specialized tools for specific tasks. That's why we're embarking on a journey to split up the developer MCP into more focused modules, such as shell and edit. This will not only make the codebase cleaner but also pave the way for future enhancements. Let's break down the details and see what this means for the project.

The Need for Splitting the Developer MCP

Right now, the developer MCP is a bit of a mixed bag, housing several tools under one umbrella. This can lead to a few challenges: Firstly, it can make the codebase harder to navigate and maintain. When everything is lumped together, it becomes difficult to quickly find and modify specific functionalities. Secondly, it limits the potential for individual tool enhancements. When tools are tightly coupled, it's harder to improve one without affecting others. Thirdly, it hinders scalability. As we add more tools to the developer MCP, it becomes increasingly unwieldy and difficult to manage.

To address these challenges, we're taking a modular approach. By splitting the developer MCP into smaller, more focused modules, we can achieve several benefits: Improved code organization. Separating tools into distinct modules makes the codebase easier to understand and maintain. Each module has a clear purpose, making it simpler to locate and modify specific functionalities. Enhanced tool-specific development. With modularity, we can enhance individual tools without affecting others. This allows us to iterate faster and deliver more targeted improvements. Greater scalability. As the project grows, modularity makes it easier to add new tools and features without creating a monolithic behemoth. We can simply create new modules and integrate them seamlessly.

As mentioned earlier, some initial steps have already been taken in PR #3976, where certain functionalities are being moved to computercontroller. This is a great first step, but we need to go further and create a more comprehensive separation. The goal is to have distinct modules for shell and edit, as well as potentially other tools in the future. This will provide a cleaner, more maintainable, and more scalable architecture for the project.

Proposed Modules: Shell and Edit

The initial focus of this split is on creating two distinct modules: shell and edit. Let's take a closer look at what each of these modules will encompass:

Shell Module

The shell module will encapsulate all functionalities related to interacting with the system shell. This includes executing commands, managing processes, and handling input/output. Think of it as the command-line interface within our system. A well-defined shell module will provide a consistent and reliable way to interact with the underlying operating system. This is crucial for many tasks, such as running scripts, managing files, and deploying applications. By having a dedicated module for shell functionalities, we can ensure that these critical operations are handled efficiently and securely.

Imagine the possibilities with a robust shell module. We could implement features like command history, tab completion, and even custom command aliases. This would greatly enhance the user experience and make it easier to work with the system. Furthermore, a modular shell component allows for easier testing and debugging. We can isolate shell-related issues and address them without affecting other parts of the system. This is a significant advantage in terms of maintainability and reliability.

Edit Module

The edit module, on the other hand, will focus on functionalities related to editing files and other text-based data. This includes opening files, reading content, making changes, and saving the updated content. A dedicated edit module is essential for tasks such as code editing, configuration file management, and content creation. By separating editing functionalities from other tools, we can create a more streamlined and efficient editing experience.

A well-designed edit module can offer a range of features, such as syntax highlighting, code completion, and version control integration. These features can significantly improve developer productivity and reduce errors. Moreover, a modular edit component can be easily extended to support different file formats and editing modes. This flexibility is crucial for adapting to evolving project needs and accommodating new technologies. Just like the shell module, a dedicated edit module simplifies testing and debugging, allowing us to focus on editing-specific issues without impacting other parts of the system.

Inspiration from Other Projects

It's always a good idea to look at how other successful projects have tackled similar challenges. In this case, we can draw inspiration from projects like Gemini CLI and Claude Code, which have already adopted a modular approach for their shell and edit functionalities. Let's examine these examples to gain insights and best practices.

Gemini CLI

Gemini CLI, a powerful command-line interface, has separate modules for shell and edit. The shell module in Gemini CLI provides a robust way to interact with the system shell, while the edit module offers a comprehensive set of editing functionalities. By examining the implementation of these modules, we can learn valuable lessons about how to structure our own shell and edit modules. For example, we can analyze the APIs they expose, the data structures they use, and the error handling mechanisms they employ.

Claude Code

Claude Code, another notable project, also adopts a similar modular approach. It has distinct components for