MCP and Caspian GitHub issue

vibecode
{"vibecode": {
    "doc": "mcp_and_caspian",
    "role": "report on how Caspian could use the Model Context Protocol (MCP). Explains what MCP is, surveys the three roles Caspian could play (MCP client for its own agents, MCP server exposing Caspian to external AI apps, and convergence with Caspian's own ACP). Recommends V1.x adoption as MCP client; V2+ consideration as MCP server.",
    "status": "report / brainstorm — no design committed; gathering context for future decisions",
    "key_concepts": ["mcp_is_anthropics_standard_for_ai_app_to_tool_integration",
        "caspian_as_mcp_client_for_its_agents",
        "caspian_as_mcp_server_for_external_ai_apps",
        "acp_and_mcp_could_layer_or_converge",
        "v1_skip_v1x_client_v2_server"]
}}

What MCP is GitHub issue

Model Context Protocol is Anthropic's open standard (launched late 2024) for connecting AI applications to external tools and data. Think of it as USB-C for AI: a uniform protocol so any AI app can plug into any tool server. JSON-RPC over stdio or HTTP.

Three primitives an MCP server provides:

Real examples already in the wild: a Filesystem MCP server (read_file, write_file, list_directory), a GitHub MCP server (issues, PRs, commits), database connectors, Slack integrations, etc. Anthropic's Claude Desktop is the canonical client; Cursor and other AI editors also speak MCP.

Mental model GitHub issue

AI app + MCP servers = AI app with augmented capabilities.

Each MCP server is its own process. The AI app spawns/connects to it on startup, learns what tools/resources it offers (via a discovery handshake), and can then call those tools as part of its reasoning. The user doesn't write "AI integration code" — they install MCP servers and the AI sees their capabilities.

Where MCP intersects with Caspian — the agent-calling spec GitHub issue

Caspian's Puckai work has the most obvious overlap:

When $agent.yield fires, the agent that wakes up to handle the call has to DO something with the world it was handed. Right now, that "do something" is opaque — the agent has its own reasoning, then returns. Where would MCP fit? Right there: the running agent could be given access to MCP tools as part of its capability set.

Three roles Caspian could play GitHub issue

A. Caspian as MCP client (for agents running inside it) GitHub issue

When $agent.yield fires and an agent starts running, the engine attaches a configured set of MCP servers to that agent's context. The agent gets to use them like any other AI app would — fetch files via the filesystem MCP, query GitHub via the GitHub MCP, hit custom domain MCPs for app-specific tools. The agent doesn't know it's running in Caspian; it just sees MCP capabilities.

This is the LOW-EFFORT, HIGH-VALUE direction. Caspian becomes an MCP client; agents running inside Caspian inherit the entire MCP ecosystem for free. Concrete plug-in points:

B. Caspian as MCP server (exposing Caspian to external AI apps) GitHub issue

The reverse: a running Caspian program exposes ITSELF as an MCP server that external AI apps (Claude Desktop, Cursor, etc.) can connect to. Caspian classes/methods/data become MCP tools/resources.

Concretely: a Puck object running as a service could be reachable from any AI app via MCP. Or a Mikobase could expose its records as MCP resources for AI-driven exploration.

This is the HARDER direction — requires designing what becomes an MCP tool vs. a resource, security model for external access, transport (HTTP vs. stdio), etc. Higher payoff but more design work.

C. ACP and MCP — convergence or coexistence GitHub issue

ACP (Caspian's Agent Communication Protocol) is for agent-to-agent inside Caspian. MCP is for agent-to-tools across the AI industry.

They don't compete — they layer. ACP handles "two agents in a worldlet collaborating." MCP handles "an agent reaching external capabilities." The question is whether ACP's wire format could be MCP-compatible, so an MCP-speaking AI app could also speak ACP. If ACP rides on MCP's transport, Caspian gets interop for free.

Why this matters GitHub issue

Without MCP: Caspian agents can do whatever Caspian gives them, and Caspian-aware AI apps can integrate via ACP. But every other AI tool in the world is invisible. To give a Caspian agent GitHub access, someone has to write a Caspian-specific GitHub adapter.

With MCP (as client): Caspian agents instantly inherit the growing ecosystem of MCP servers — filesystem, GitHub, Notion, Slack, custom databases, anything else built for the MCP standard. The agent's capabilities are extensible without changing Caspian.

With MCP (as server): Caspian applications become first-class participants in the AI ecosystem. Someone using Claude Desktop, Cursor, or any other MCP client can point their AI at a Caspian app and use its functionality.

Risks and limitations GitHub issue

Implementation surface for Caspian-as-MCP-client (the easier direction) GitHub issue

That's roughly a slice of work — not huge. Could ship in a V1.x without disturbing the core engine.

Recommendation GitHub issue

Worth filing two tracking issues — one for "MCP client integration for Caspian agents" and one for "Expose Caspian as an MCP server" — even if neither moves until post-V1. Captures the design space without committing to it.

Where it would plug in concretely GitHub issue

Net: MCP doesn't replace anything Caspian already has, but it would multiply what Caspian agents can DO at low engineering cost. The agent-calling spec is exactly the right place to plug it in.
© 2026 Puck.uno