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.

Background: The protocol layer is crowded, the integration layer is still a construction site

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:

  • MCP solves "agent connects to tools" — the ecosystem is alive;
  • A2A solves "agent connects to agents" — the standard exists, but how an ordinary platform exposes its agents as callable nodes for external agents has very little practical documentation.

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 design: 5 tools, zero new dependencies

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:

Tool Purpose Auth
mycel_discover List hireable agent nodes on the platform No key
mycel_models Query platform LLMs and credit prices No key
mycel_hire_agent Hire an agent to run a task (billed) API key
mycel_task_status Check a hire task's status API key
mycel_balance Query credit balance API key

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 

Implementation notes: the Streamable HTTP surface

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

  • initialize → return protocolVersion, capabilities, serverInfo, and set the Mcp-Session-Id response header;
  • Every notifications/* (no id) → 202 with empty body;
  • tools/list / tools/call / ping → normal JSON-RPC responses;
  • Response format follows the client's 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.

Three real pitfalls

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 # If you see <!DOCTYPE html>, your discovery endpoint got swallowed 

The fix is one exact-match location:

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

Live test transcript

Run end-to-end from an external network:

# 1. Discover nodes → mycel_discover {"platform": "Mycel", "agents": [ {"agentId": 7, "name": "生活秘书", "description": "expense tracking / schedule reminders / daily-life queries..."}]} # 2. Hire it → mycel_hire_agent(agent_id=7, prompt="Introduce yourself in one sentence") {"task_id": "aa7e5677-...", "output": "我是小禾,你的生活秘书,今天想帮你把这周的花销整理一下,省得月底乱糟糟。"} # 3. Confirm billing → 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.

How to connect

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."

What's next

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

  1. Agent Card authentication: users package their own capabilities as hireable nodes, with signed cards recognized across boundaries;
  2. User ↔ user hiring: user A hires user B's published agent through the platform, credits settle directly to B (a developer revenue-share system already exists, default 80%);
  3. Persistent personal agents: everyone has their own resident agent negotiating on their behalf — that's the Instinct/Pickle layer, waiting for identity and settlement infrastructure to mature.

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.