n8n is already running self-hosted on CT 102 and is the active orchestration layer for the bud pipeline, so this is an upgrade to existing infrastructure rather than a new dependency. The MCP client/server support slots directly into a system already in production use.
The upgrade reduces custom integration code (ad-hoc HTTP Request nodes) in favor of a standard protocol, matching the operator's preference for practical, low-maintenance systems that run unattended. It is an incremental improvement to a dependency already trusted, not an experimental new tool.
Implementation Options
01Upgrade n8n and convert bud's HTTP nodes to MCP client nodes
bud2-4 hourslow risk
Update the self-hosted n8n instance on CT 102 to a version with native MCP client support (docker compose pull + up). Verify the existing bud email-to-Supabase workflow still executes correctly post-upgrade, then identify the HTTP Request nodes calling MCP-compatible services (GitHub, Supabase) and replace them one at a time with native MCP client nodes, testing each swap before moving to the next.
+Removes custom HTTP glue code from an active production workflow
+Incremental and reversible - nodes can be swapped one at a time with rollback per node
+Directly addresses a documented pain point in bud's current architecture
-Any self-hosted n8n version upgrade risks breaking existing workflows and needs a full regression pass on bud before trusting it unattended
-MCP client node support in n8n is new and may have rough edges compared to mature HTTP Request nodes
02Expose n8n workflows as MCP servers for agent-triggered automation
field-notes4-8 hoursmedium risk
Use n8n's new MCP server mode to expose selected bud or field-notes workflows (e.g. trigger an enrichment re-run, kick off a specific automation) as MCP tools that CCR agents or Claude Code sessions can call directly instead of via webhook.
+Lets agents trigger n8n automations without maintaining separate webhook/API glue
+Fits the broader multi-agent direction of field-notes and bud
-No current concrete workflow needs this - it is speculative rather than solving an existing pain point
-Adds new surface exposed through the Cloudflare tunnel that needs its own access control review
bud's n8n pipeline currently reaches GitHub and Supabase through custom HTTP Request nodes. Swapping those for native MCP client nodes removes that hand-built glue code and standardizes bud's integration layer on MCP, so future services that ship an MCP server plug in without writing another custom node.
As MCP becomes the default tool-interop protocol, having the self-hosted workflow layer speak it natively cuts integration debt for a solo operator maintaining several unattended systems (bud, field-notes) on limited time. Each new HTTP node avoided is one less thing to maintain when APIs change.
03 · What Implementation Looks Like This is an infra/workflow change, not a code change to any repo: pull the updated n8n image on CT 102, redeploy, run the existing bud email-intake workflow end to end to confirm no regression, then open the bud workflow in the n8n editor, replace one HTTP Request node calling Supabase or GitHub with the new MCP client node, and re-test that single path before converting the rest. A minimal v1 is one node converted and verified, not a full pipeline rewrite.