Proposal: Implement Model Context Protocol (MCP) for Extensible External Tooling & Dataset Access

[aniruddhaadak80]

Currently, the autoresearch agent relies on hardcoded Python tool functions. By adopting the open-standard Model Context Protocol (MCP), the agent could seamlessly connect to an ecosystem of pre-built MCP servers.

This would futuristically enable:

1. Direct read/write access to specialized databases (e.g., Pinecone for semantic memory of past experiments).
2. Interfacing with GitHub/arXiv MCP servers to automatically pull in State-of-the-Art papers before proposing an idea.
3. Decoupled, sandboxed execution environments via Docker MCP servers, separating the LLM brain from the execution host.

This standardizes how tools are given to the researcher model, moving away from bespoke prompt injection into a robust client-server architecture.

[morozow]

This is actually already achievable with the existing stdio Bus architecture — no need to rebuild the tool layer from scratch. The mcp-to-acp-proxy bridges MCP protocol to stdio Bus transport:

sequenceDiagram
    participant Agent as Agent<br/>(MCP Client)
    participant Proxy as mcp-to-acp-proxy
    participant Bus as stdio Bus<br/>Kernel
    participant Registry as acp-registry
    participant Worker as Worker<br/>(Pinecone/GitHub/Docker)

    Note over Agent,Worker: MCP tools/call → ACP session/prompt conversion

    Agent->>Proxy: MCP initialize<br/>{"protocolVersion": "2024-11-05"}
    Proxy->>Bus: ACP initialize<br/>{"agentId": "target-worker"}
    Bus->>Registry: Route by agentId
    Registry->>Worker: Spawn/reuse process
    Worker-->>Registry: Ready
    Registry-->>Bus: Session created
    Bus-->>Proxy: ACP response
    Proxy-->>Agent: MCP response

    Note over Agent,Worker: Tool execution flow

    Agent->>Proxy: MCP tools/list
    Proxy->>Bus: ACP session/new
    Bus->>Registry: Get worker capabilities
    Registry-->>Bus: Available methods
    Bus-->>Proxy: ACP tools as prompts
    Proxy-->>Agent: MCP tools schema

    Agent->>Proxy: MCP tools/call<br/>{"name": "pinecone_query", "arguments": {...}}
    Proxy->>Bus: ACP session/prompt<br/>{"prompt": "pinecone_query {...}"}
    Bus->>Registry: Route to worker
    Registry->>Worker: Execute query
    Worker-->>Registry: Result
    Registry-->>Bus: Response
    Bus-->>Proxy: ACP response
    Proxy-->>Agent: MCP tool result

    Note over Agent,Worker: Agent sees only MCP — routing is transparent

Loading

From the agent's perspective, it's just speaking MCP. The proxy serializes to ACP, and stdio Bus routes to any worker in the acp-registry – including custom workers for Pinecone, GitHub, arXiv, or sandboxed Docker execution. The decoupling you're describing – LLM brain separate from execution host – is exactly what stdio Bus provides: the kernel handles message routing, workers handle execution, and the agent doesn't care where things run.

One consideration: the 5-minute training budget means external API calls – arXiv lookups, vector DB queries – should happen before experiment initiated, not during. stdio Bus worker pools support this – parallel analysis workers can prefetch and cache results, feeding them to the dispatcher before GPU time starts.

Happy to discuss specific integration patterns if useful.