Feature: Implement Model Context Protocol (MCP) support for extensible operations

[Zepan]

Overview

As part of our Operations Roadmap, we aim to integrate the Model Context Protocol (MCP) into PicoClaw. MCP is an open standard that enables seamless integration between AI models and external data sources or tools. By supporting MCP, PicoClaw will be able to instantly connect to a vast ecosystem of existing MCP servers (e.g., Google Drive, Slack, GitHub, local databases) without requiring custom-coded "Skills" for every service.

Core Requirements

• MCP Client Implementation: Build a robust MCP client within the PicoClaw core (Go-based) to communicate with external MCP servers.
• Dynamic Tool Discovery: Enable PicoClaw to fetch tool definitions and resource schemas from connected MCP servers at runtime.
• Secure Execution: Ensure that MCP tool calls are handled within PicoClaw's permission framework to maintain AI safety and security.
• Configuration Management: Provide a simple way for users to add and manage MCP server endpoints in the PicoClaw configuration.

Expected Workflow

1. Configuration: The user adds an MCP server (e.g., a local Python script or a remote API) to their config.yaml.
2. Connection: Upon startup, PicoClaw initializes the MCP client and "handshakes" with the server.
3. Operation: When a user asks a question requiring external data, PicoClaw uses the MCP protocol to fetch context or execute tools via the connected server.

Why this matters?

Adding MCP support transforms PicoClaw from a standalone bot into a powerful "AIEOS" hub, capable of orchestrating complex workflows across any platform that supports the protocol.

[nikolasdehor]

MCP support would be a major force multiplier for PicoClaw. Here is a practical implementation plan that fits the existing architecture:

Phase 1: MCP client (stdio transport)

The simplest and most useful MCP integration is via stdio transport — PicoClaw spawns a local MCP server process and communicates over stdin/stdout using JSON-RPC 2.0. This covers the majority of MCP servers in the ecosystem (filesystem, GitHub, Slack, databases, etc.).

The Go implementation is straightforward since PicoClaw already has ExecTool infrastructure for spawning processes:

type MCPClient struct {
    cmd     *exec.Cmd
    stdin   io.WriteCloser
    stdout  *bufio.Scanner
    tools   []MCPToolDef // discovered at handshake
    mu      sync.Mutex
}

func (c *MCPClient) Initialize() error {
    // Send initialize request
    req := jsonrpc.Request{Method: "initialize", Params: map[string]interface{}{
        "protocolVersion": "2025-03-26",
        "capabilities":    map[string]interface{}{},
        "clientInfo":      map[string]string{"name": "picoclaw", "version": Version},
    }}
    resp, err := c.send(req)
    if err != nil {
        return err
    }
    // Send initialized notification
    c.send(jsonrpc.Request{Method: "notifications/initialized"})
    // Discover tools
    return c.listTools()
}

Phase 2: Dynamic tool registration

Once MCP tools are discovered via tools/list, they need to be registered as PicoClaw tools so the LLM can invoke them. The key design decision: MCP tools should be wrapped as native PicoClaw tools with the same permission framework:

func (c *MCPClient) RegisterTools(registry *tools.Registry) {
    for _, tool := range c.tools {
        registry.Register(tools.Tool{
            Name:        "mcp_" + tool.Name, // prefix to avoid conflicts
            Description: tool.Description,
            Parameters:  tool.InputSchema,
            Execute: func(args map[string]interface{}) (string, error) {
                return c.CallTool(tool.Name, args)
            },
        })
    }
}

Phase 3: Configuration

{
    "mcp": {
        "servers": {
            "filesystem": {
                "command": "npx",
                "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/documents"],
                "enabled": true
            },
            "github": {
                "command": "npx",
                "args": ["-y", "@modelcontextprotocol/server-github"],
                "env": {"GITHUB_TOKEN": "${GITHUB_TOKEN}"},
                "enabled": true
            }
        }
    }
}

Security considerations:

1. Tool approval: MCP tools should go through the same permission framework as native tools. The ExecTool allow_from / deny patterns should apply to mcp_* tools as well.
2. Process lifecycle: MCP server processes must be managed (health checks, restart on crash, clean shutdown on gateway stop).
3. Resource limits: On embedded devices (MaixCam/64MB RAM), spawning Node.js MCP servers is not practical. The config should support a transport: "sse" option for connecting to remote MCP servers over HTTP instead of spawning local processes.

Implementation order I would suggest:

1. stdio transport client with initialize + tools/list + tools/call
2. Config parsing and server lifecycle management
3. Dynamic tool registration into PicoClaw tool registry
4. SSE transport for remote servers (Phase 2)
5. Resources and prompts support (Phase 3 — lower priority)

This is a good candidate for a phased PR series. I would be interested in contributing to Phase 1 if maintainers agree on the approach.

[reustle]

Merged by nanobot recently (the spiritual successor to picoclaw), may be able to pull some useful info from it.

HKUDS/nanobot#554

[nikolasdehor]

@reustle Good reference — the nanobot MCP implementation (HKUDS/nanobot#74) uses stdio transport which is the right starting point. PicoClaw could adapt a similar approach:

1. Stdio transport for local MCP servers (same as nanobot)
2. Tool registration bridge to map MCP tools into PicoClaw's existing ToolDefinition registry
3. SSE transport as a follow-up for remote/embedded scenarios

The key difference is PicoClaw's permission framework — MCP tools would need to go through the same allow_patterns/deny_patterns security checks as native tools.

[yinwm]

There's a PR #282 , it could be the answer

[alexkutsan]

Waiting for this feature.
Without MCP support it is pretty hard to make this agent properly communicate with external world.