Mycel 如何用零新增依賴的 MCP 伺服器讓外部 Agent 聘用平台智能體
Wiring Your AI Agent into a "Mycelium Network": A Zero-Dependency MCP Server in Production
Mycel 以一個零新增依賴的 MCP 伺服器,讓外部 Agent 搜尋並按任務付費聘用平台上的 Agent。伺服器提供 5 項工具,聘用請求轉交內部 A2A v1.0 gateway,沿用既有執行、計費和存取控制;搜尋及模型查詢則不需 API key。
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→ returnprotocolVersion,capabilities,serverInfo, and set theMcp-Session-Idresponse header; - Every
notifications/*(no id) → 202 with empty body; -
tools/list/tools/call/ping→ normal JSON-RPC responses; - Response format follows the client's
Acceptheader: includeapplication/jsonand 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:
- Agent Card authentication: users package their own capabilities as hireable nodes, with signed cards recognized across boundaries;
- 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%);
- 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.
來源:DEV Community · dev.to