Building your own Claude glue vs a shared layer: what to build, what to hand over
By Soumen Sarkar · October 2026
Comparison. If you need Claude to act on a tool, build the glue yourself: an MCP server, a hook, a Slack webhook. If you need every session to know what the team decided, use a shared layer like Campfyrr, because that glue breaks quietly. Most teams need both.
What are you trying to fix?
If you need Claude to act on a tool, build the glue yourself. If you need every session to know what the team decided, use a shared layer like Campfyrr, because that kind of glue breaks quietly. Most teams need both.
Ask of each piece of glue: does it act on a tool, or does it carry what the team knows?
- "I want Claude to open issues, read our dashboard, post to a channel." Build it, or install a ready-made server. GitHub publishes an official MCP server for repositories, issues, pull requests and Actions. A shared
.mcp.json at the project root gives "everyone on your team the same MCP tools and services" (Claude Code MCP docs). - "I want one local rule enforced: block that command, format that file." A Claude Code hook is the right tool.
- "My teammates' sessions keep building on decisions we already changed." That's context, not a connector. Campfyrr.
The same day, with each
This is a scene, not a customer. A tech lead and three developers work on one service. On Monday the lead decides to move payments to the new client library, and writes it in decisions.md.
With your own glue. A SessionStart hook pastes decisions.md into every session. It worked last month. This week someone moved the file during a tidy-up, so the script exits with an error. Any exit code other than 2 is a non-blocking error, and the session goes ahead (Claude Code hooks). That's the right default, but a broken context script now looks exactly like a working one with nothing to say. A second developer works in a cloud session, which doesn't load the plugins in her local settings (Claude Code plugins), so she never had the hook at all. Both agents do good work on the old library. The lead spots it in review on Wednesday, and two afternoons go into redoing it. Nobody did anything wrong. The glue failed silently, and nothing told anyone.
With Campfyrr. The lead's decision is recorded with its reason and who made it, and the older one is marked replaced. The first time either developer's session edits the payments folder, it gets an area brief: the decision that applies, the work in progress there, and what was assumed. The cloud session gets the same brief, because Campfyrr runs in cloud sessions too. Nobody runs a command. To be fair, Campfyrr's own hooks follow the same rule yours do: they never block a session, and they stay quiet when Campfyrr can't be reached. Our own cloud sessions are turned away with "Missing or invalid bearer token" whenever CAMPFYRR_TOKEN isn't set, and they keep working without briefs. The difference is that there is one install to keep working, not a script per teammate. See what a session gets.
When building it yourself is the better choice
Build it yourself, and mean it, when:
- The tool is internal and no ready-made MCP server exists for it.
- The job acts on a system: post this, fetch that, block that command. Campfyrr doesn't open issues, sync your tracker or run CI.
- Your rules say no team data leaves your network. Campfyrr never takes your code, but it does keep file paths and what happened (trust).
- You're one or two people, and one shared CLAUDE.md that you both read is enough.
- You want a bot that answers in Slack. Campfyrr posts milestones there but doesn't read Slack.
What it costs
Take 5 developers and 3 business teammates. Your own glue costs nothing but time. Campfyrr is $9 per developer a month, minimum 3 developers ($7 billed yearly): five developers at $7 is $35 a month billed yearly, or $45 monthly. The three business teammates read and answer for free, and everything is free during early access (pricing).
The cost that matters more is who keeps it working. With your own glue, someone owns the scripts, keeps decisions.md current by hand, and notices when a hook has stopped saying anything. A script can paste a file into every session, but it can't tell which decision applies to the file being edited, notice that a newer decision replaced an older one, or send an agent's assumption to the person who can confirm it. Writing that is building a product. With Campfyrr, someone sets the token once per environment, and agents record decisions as they work.
Verdict
Build it yourself if the glue acts on a tool, the tool is yours alone, or your data can't leave your network. Package it as a plugin so teammates install it with one command.
Choose Campfyrr if several people run several sessions and your context scripts are the ones that keep breaking, or the business needs to see and answer what agents assumed.
Use both if you have connectors worth keeping. List every hook, script and MCP server, and mark each "acts on a tool" or "carries team context". Keep the first kind in a shared .mcp.json. Install Campfyrr from /connect, and remove each context script once the briefs cover it.
The wider problem is making Claude handle every system. See also what MCP does for a team, the hooks playbook, and every product in this space in our research.
The problem this answers: Claude across every system: "We tried to make Claude handle all our moving systems ourselves, and the glue became the project."
The principle behind this: Decide by doing: Our decisions live in what we do, not in what we say.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).