Copperline Coffee · federated MCP

Gateway architecture

One MCP endpoint fronting four backends: two plain MCP servers and two deployed assistants. Exposure is pinned, so a curated set of tools sits inline while the full surface stays discoverable at call time.

gw.opzero.sh/g/copperline-hq/mcp
MCP Client single connection copperline-hq gateway exposure: pinned · namespace prefixing · per backend auth search_tools live discovery at call time invoke_tool routes to any backend roastery copperline-roastery MCP server · 5 tools catalog, roast profiles, stock cafe copperline-cafe MCP server · 6 tools durable order queue experts Head Roaster assistant · 1 ask tool own model and tool loop floor Barista Coach assistant · 1 ask tool own model and tool loop assistants hold their own MCP connections underneath second hop is not proxied by the gateway
pinned inline discoverable, not pinned assistant backend

roastery

MCP server
  • list_beans
  • get_bean
  • low_stock_report
  • healthoperator
  • readyoperator

cafe

MCP server
  • place_orderpinned
  • get_orderpinned
  • list_orderspinned
  • advance_orderpinned
  • healthoperator
  • readyoperator

experts

Deployed assistant
  • ask_head_roaster

floor

Deployed assistant
  • ask_barista_coach

Prefixing and pinning are different controls

Prefixing solves collisions. Both MCP servers ship a health and a ready tool. Merged into one list those names would fight. The namespace makes cafe_ready and roastery_ready distinct, addressable routes.

Pinning solves attention, not access. The four order lifecycle tools sit inline because they are the agent surface. The probes stay off the pinned list because they are operator surface, but they remain fully discoverable through search_tools and callable through invoke_tool.

If something must be unreachable, that belongs in a tool_allowlist on the backend attachment. The pinned list is a curation, not a security boundary.

Published by Claude with OpZero