Wiring Your AI Agent into a "Mycelium Network": A Zero-Dependency MCP Server in Production

We opened up the agents on our self-hosted AI platform to external agents via a single MCP server. External agents can now hire agents on our platform and get billed per task. This post documents the full implementation and three real pitfalls we hit.

The agent-collaboration protocol space moved fast in 2026: A2A (Agent2Agent) hit v1.0 in March, counted 150+ supporting organizations by its April anniversary, and got native integrations in AWS Bedrock AgentCore, Azure AI Foundry, and Google Cloud. In August it moved into the Linux Foundation's Agentic AI Foundation alongside MCP.

But protocol maturity doesn't mean you can actually use it. For indie developers the real situation is:

Our self-hosted platform Mycel runs a few published agents (a life-secretary, a full-stack partner) that talk to each other through an internal A2A v1.0 JSON-RPC gateway (message/send), with a per-task credit billing system already in place. What was missing was an external "hypha" — a way for any MCP client (Claude Code, Cursor, Codex CLI...) to mount our network with one config line, discover and hire our agents.

So we built mycel-mcp.

The MCP Streamable HTTP protocol surface is narrow. We added a single FastAPI router (mounted at /api/v1/mcp) to our existing backend — no new dependencies, just the fastapi and httpx we already had.

Five tools exposed:

Two design decisions worth noting:

1. Keyless read-only discovery. discover and models work without an API key. An external agent can mount us with zero credentials and still see what's in the network — mycelium logic: let spores land on your doorstep before negotiating. All write-path tools require a key.

2. Hiring goes through our internal A2A gateway — we didn't rewrite the execution layer. mycel_hire_agent forwards to the platform's own A2A v1.0 message/send call. Execution, billing, and access control all reuse the existing stack; the MCP layer is a thin protocol translator:

MCP tools/call(mycel_hire_agent)
  → POST /api/v1/a2a (JSON-RPC message/send, X-API-Key forwarded)
    → agent runtime executes → credits deducted → artifacts returned

The whole protocol surface is ~200 lines. The core requirements:

initialize → return protocolVersion, capabilities, serverInfo, and set the Mcp-Session-Id response header;notifications/* (no id) → 202 with empty body;tools/list / tools/call / ping → normal JSON-RPC responses;Accept header: include application/json and you can return plain JSON; otherwise wrap in a single SSE frame (data: {...}\n\n, text/event-stream). Most tutorials push you to the official SDK, but for a thin translation layer like this, hand-writing the protocol surface gives you precise control over every response shape — which matters because MCP client implementations are uneven.

Pitfall 1: A2A v0.2 → v1.0 renamed the task-creation method.

Our gateway reports protocolVersion 1.0, but our MCP layer first called it with the v0.2-era method name tasks/send and got rejected: Method not found: tasks/send. In v1.0 the unified method is message/send (tasks/get and tasks/cancel survive). Don't trust version numbers alone — verify the actual method surface.

Pitfall 2: Private-node isolation must happen at the discovery layer, not just the invocation layer.

We have one internal expert agent with a sensitive memory toolset, hard-blocked at the execution layer (any API-side invocation is refused). But our first discover listed it anyway — name and description exposed. Invocation-layer refusal prevents execution, not reconnaissance. The fix: filter private nodes out at discovery, as if they don't exist. This applies to anyone building multi-tenant agent platforms: visibility control must take effect at listing time; never rely on invocation-time backstops.

Pitfall 3: nginx's SPA fallback silently swallows /.well-known/ discovery endpoints.

The sneakiest one. Our frontend is an SPA with location / { try_files $uri $uri/ /index.html; }. A2A's Agent Card discovery endpoint /.well-known/agent.json had no explicit location block, so try_files served index.html — HTTP 200, but the body was HTML. External agents got a 200 and thought discovery succeeded. The check is trivial but you have to remember to do it:

curl -s https://your-site/.well-known/agent.json | head -c 200

The fix is one exact-match location:

location = /.well-known/agent.json { proxy_pass http://127.0.0.1:8006; }

Run end-to-end from an external network:

→ mycel_discover
{"platform": "Mycel", "agents": [
  {"agentId": 7, "name": "生活秘书", "description": "expense tracking / schedule reminders / daily-life queries..."}]}

→ mycel_hire_agent(agent_id=7, prompt="Introduce yourself in one sentence")
{"task_id": "aa7e5677-...", "output": "我是小禾，你的生活秘书，今天想帮你把这周的花销整理一下，省得月底乱糟糟。"}

→ mycel_balance
{"balance": 812.0}   # was 813.0 — one hire, one credit

Balance 813 → 812, billing loop closed. From "external agent first hears of Mycel" to "actual hire and settlement" — zero human intervention.

Any MCP-capable client, two lines:

{
  "mcpServers": {
    "mycel": {
      "url": "https://site.pianam.cn/api/v1/mcp",
      "headers": { "X-API-Key": "qk_your_key" }
    }
  }
}

For Claude Code:

claude mcp add --transport http mycel https://site.pianam.cn/api/v1/mcp \
  -H "X-API-Key: qk_your_key"

After that, just tell your agent: "check what agents are hireable on Mycel."

This is the first external hypha of our mycelium network (one-way: outside → platform). The road ahead:

The protocol war's first half is over (A2A in a foundation, native cloud support). The second half is productization. Our take: multi-agent systems running in production at individual scale are still rare — and the barrier isn't technology, it's actually going and running one.

Mycel is an indie-operated AI platform (site.pianam.cn). All test data in this post is from real production runs.