Add support for Model Context Protocol (MCP) via stdio transport

[knightdave]

Thank you for adding support for Model Context Protocol (MCP) – this opens up valuable extensibility options.

Currently, it appears that MCP integration only supports remote (network-based) endpoints. I would like to request adding support for the stdio transport method, as defined by the MCP specification.

Use case:

I am working on extending mycoder to support GitLab, similarly to how GitHub is already integrated. There are already existing MCP-compatible agents that expose GitLab context via stdio (e.g. local daemons, shell-based MCP agents, or language-specific tooling), and being able to leverage them would significantly reduce the implementation complexity.

By supporting MCP over stdio, it becomes feasible to plug in a wide range of existing, local tooling with minimal friction.

Proposed benefit:

• Enables integration with local MCP agents without requiring network setup
• Unlocks GitLab support via existing stdio-based MCP tooling
• Better alignment with the flexibility intended by the MCP spec
• Encourages broader adoption of mycoder in environments with strict security policies

Let me know if you're open to this addition — I’d be happy to contribute or help test.

Related Issues

#240

[bhouston]

Issue Triage Summary

Thank you for submitting this feature request! I've triaged the issue and here are my findings:

Classification

• Type: Feature enhancement
• Labels: enhancement, help wanted

Assessment

This is a valid feature request that aligns with the project's goals. The MCP SDK already has stdio transport support, making implementation feasible.

Technical Details

Adding stdio transport support would require:

1. Extending the McpServerConfig interface to include transport type ('network' or 'stdio')
2. Adding configuration options for stdio transport (command to execute, arguments)
3. Modifying the createMcpTool function to initialize either a network client or stdio client
4. Adding appropriate error handling and logging

Benefits

• Enables integration with local MCP agents without requiring network setup
• Facilitates GitLab support via existing stdio-based MCP tooling
• Better alignment with the flexibility intended by the MCP spec
• Encourages broader adoption in environments with strict security policies

Next Steps

We'll add this to our backlog for consideration. Since you've offered to contribute or help test, would you be interested in working on a PR for this feature? If so, I'd be happy to provide guidance on implementation details.

Questions

• Do you have specific examples of stdio-based MCP agents that you're planning to use with this feature?
• Any specific functionality beyond basic stdio transport that would be important for your use case?

[knightdave]

/mycoder Thanks for the detailed triage and follow-up. I'm glad to hear the enhancement aligns with the project goals. Below are answers to your questions and a few important considerations for implementation.

1. Specific examples of stdio-based MCP agents

Yes – we're working with existing MCP stdio agents hosted in the official [modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers) repository. A specific example relevant to this use case is:

• [server-gitlab](https://github.com/modelcontextprotocol/servers/tree/main/src/gitlab)

This tool exposes GitLab context via stdio and is already compatible with the MCP protocol.

2. Additional functionality and implementation considerations

There are a couple of important behaviors to account for when implementing stdio transport:

• Startup latency:
  Some stdio-based MCP agents require time to start – e.g. pulling docker images, downloading dependencies via npx, or initializing environments.
  The system should wait for the process to become ready before proceeding to prompt the user.

• Startup diagnostics:
  At the beginning of a prompt (or tool startup), it would be very helpful to show the status of each MCP server (e.g., “ready”, “failed to start”, “timeout”) – this makes it clear which sources are active and helps debugging configuration issues.

• Configuration detection:
  Stdio vs network MCP servers can be distinguished by the presence of command and args fields in config. Example config below shows mixed usage of remote and local stdio transports:

// mycoder.config.js
export default {
    mcp: {
        servers: [{
                // Remote MCP server
                name: 'company-docs',
                url: 'https://mcp.example.com/docs',
                auth: {
                    type: 'bearer',
                    token: process.env.MCP_SERVER_TOKEN,
                },
            },
            {
                // Stdio: Docker-based agent (local dev/testing)
                name: 'gitlab',
                command: "docker",
                args: ["-run", "--rm", "-i", "-e", "GITLAB_PERSONAL_ACCESS_TOKEN", "-e", "GITLAB_API_URL", "mcp/gitlab"],
                env: {
                    "GITLAB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>",
                    "GITLAB_API_URL": "https://gitlab.com/api/v4" // Optional, for self-hosted instances
                }
            },
            {
                // Stdio: Git agent running via uv
                name: 'git',
                command: "uv",
                args: ["--directory", "/path/to/allowed/files", "/ABSOLUTE/PATH/TO/PARENT/FOLDER/git", "run", "mcp-server-git"]
            },
            {
                // Stdio: GitHub agent with custom environment
                name: 'github',
                command: "npx",
                args: ["-y", "@modelcontextprotocol/server-github"],
                env: {
                    "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
                }
            }
        ],
        defaultResources: ['company-docs://api/reference'],
    },
};

I'm happy to contribute a PR or collaborate on this – just let me know your preferred approach and any structure you'd like followed for the implementation.

Let me know if you want me to proceed with a draft PR.