Andreas Bolz is a staff engineer at Snitcher. The MCP is his third oversized project here after Radar and the billing revamp, and it lets Claude, ChatGPT and friends work straight from your Snitcher data.
More of a release-notes person? Here’s the feature rundown.
Let’s start at the beginning. You did humanities at uni. How does that end in staff engineering?
‘Twas the money, bro.
No, to be fair, I got a bit burned out on academic work and I remembered I was pretty good at programming from high school, so I decided to do that for a while. The plan was a year or so of it, refresh my skills and then try to go into data-driven journalism or something like that. But if you’re good at something you might as well get paid for it, and if you can get paid well for it, see ya academia.
Before we carry on, what is an MCP?
It’s basically an annotated API, which is an API that’s optimised for an LLM to work with. It’s a list of tools the LLM can call, with a bunch of explanation around them so it knows how to call each tool and how to read what comes back. Like, the ID that comes out of this tool is what you feed into that one.
You also get to give it extra context a normal API can’t, like what Snitcher is and what an ideal workspace configuration looks like. So when someone plugs their LLM into Snitcher with some goal in mind, the LLM can be the middleman that handles all that complexity and just gets things done.
So, who decided we needed an MCP?
It wasn’t really anyone’s call. MCP is a protocol Anthropic put out for agents to talk to pretty much any service, and once companies here and there started implementing it, we could see it had use. It kept getting mentioned as one of those “this would be nice to have” things.
At some point we realised this is just another form of interface and it’s going to get more and more universal as people do more of their work through Claude and tools like it. If someone spends three quarters of their day inside Claude and it can’t connect to Snitcher, then the person behind the laptop has to do the bridging. Go into Snitcher, pull a bunch of data out and paste it into Claude. That’s just going to be a ball ache.
Snitcher already has a dashboard and an API. Why the MCP?
If you’ve only got an API, something like Claude Code is probably smart enough to grab an API token and start calling it directly. But Claude Desktop can’t do that natively — it can’t run commands on your machine. So it all gets really fiddly. You might end up with the same result, but it’d cost way more tokens and it’s just a way less efficient way for an LLM to talk to us.
The bigger reason is who it’s for. Most companies that use us have a couple of champions around the product and then a bunch of people who get nudged by stuff coming out of Snitcher every now and then but aren’t core users. If you can meet those people where they actually work, you should.
It’s the same thinking behind our Slack stuff: if the salespeople live in Slack and not in Snitcher, make the Slack experience rich enough that they don’t have to be in Snitcher.
Walk me through how it came together.
It’s funny, because the first build took about a week. Getting a version of it up was pretty easy. But nobody’s built something like this before — it’s a new paradigm you’ve got no experience with. It’s one thing to tell Claude, we need an MCP, this is our platform, go build it out for me. Getting from there to something that’s actually useful, secure, efficient on tokens and easy to discover… That’s where all the work is.
The first version didn’t have an OAuth flow, for example. Connecting meant editing some file on your system so Claude would know how to talk to it. Fine for me, ridiculous for a customer. Then we got pen-tested as part of our ISO preparations, some useful insights came out of that and we tightened up security a bit more. We ended up splitting it into two servers: a customer-facing MCP, which covers anything you’d normally do in your workspace, and a staff one that’s been replacing our internal admin tooling.
Nobody ever sees your work, though. So what were you actually designing?
Mostly the annotations. Every tool the LLM can call comes with explanations: when to use it, how to read what comes out and what to call next with the result. Plus that bigger-picture context about what Snitcher is and what a well-configured workspace looks like. Get those right and the LLM can find its way through everything. Get them wrong and you see it pretty quickly.
Whenever Claude thinks it should use a tool a certain way and it keeps not working out that way, that usually means the annotations on that tool aren’t perfect yet. That’s basically my day-to-day on it now, watching the activity log for tools erroring out and tightening the setup.
Some of these tools write straight into a customer’s CRM. Did that scare you?
It’s definitely the part you have to get right, yeah. Anything that writes data should have a dry-run capability. Tools that are potentially destructive force you to explicitly allow the call. And anything that’s a monetary action, like revealing emails or phone numbers, will always check with you before it spends credits. Scale also matters. If you tell it, hey, fix this for me, and it’s suddenly about to write to a hundred workspaces, it should probably double-check that’s actually what you want.
You don’t want to go too far with it. You want a lot of that early on, until you’ve decided Claude is pretty trustworthy and it won’t do anything stupid. After that it just gets annoying if it keeps asking, should I do this, should I do that, about things you’ve done a hundred times. Finding that balance is a bit of a journey of discovery.
It’s better to be a bit restrictive at first and then realise, oh, these guardrails aren’t necessary, than to go the other way around. I built this on a whim as a proof of concept, and you want something like that to prove itself slowly. Not, hey, I ran a Claude session and now everyone’s fucked up their workspaces. That’s not ideal.
How do you test something with no interface?
That’s the frustrating part of building this: you only see the tool calls. You don’t see what people are actually asking their Claude.
A lot depends on the quality of the model on the other end. If you’re on Claude Opus or Fable, then even if a tool would let it do something stupid, the model itself is smart enough not to. Which actually makes testing harder for me, because my Claude knows so much about Snitcher by now. When I’m testing it myself, I’ve got no idea whether the things that are obvious to my version of Claude will be obvious to one with no context, or a less capable one.
The nice part is the feedback loop is sort of built in now. I made myself a triage tool in the staff MCP that looks at whichever tools errored in the last day and feeds that straight into a ticket. It kind of self-improves and it’s pretty easy to work on, honestly.
What’s the dumbest thing you watched it do?
The dumb stuff mostly doesn’t happen. A good model won’t take the stupid option just because a tool offers it. The memorable stuff is more people using it way harder than we’d planned for.
Like, there was this dude who did 700 tool calls in a session. We paused his access because we thought he might be malicious. Turned out he was a completely legitimate user, just building himself an outbound list. But those calls were draining our enrichment budget, so we had to build some throttling around it pretty quickly. You don’t realise until someone actually starts doing it. And once one user finds a use case like that, the rest will too.
Someone connects it today. What should their first message be?
Whatever you were already trying to do, honestly. We hadn’t even announced it and people were finding it anyway, all using it in different ways. It’s literally a self-explaining tool.
If you want a proper answer: setup. Snitcher is pretty config-heavy. You need to understand a bunch of things and configure them, and the value is downstream from there, which is sometimes a big ask. With all that config exposed through the MCP, you just discover capabilities through the natural back-and-forth of a chat, and you end up configuring things in a more advanced way than you would have by pointing and clicking through the interface.
The underrated one is that your Claude probably has your CRM connected too. So have it look at your CRM next to your Snitcher setup: what data is sitting over there that Snitcher should know about, set up the field mappings so it ends up here, sharpen your segments with it. It’s a bridge between different services, and you end up getting more value out of both. And nobody’s doing the bridging by hand anymore.
Any lessons?
That there’s not really a notion of what the MCP has to do next, I guess. We just develop the platform, and the MCP stays in sync with it, exposing whatever we build in whatever way suits that interface. There’ll always be a UI equivalent. It might just ship second.
And there’s more coming on the actioning side. A lot of what people do with our data now happens outside our walls and we want that feeding back into the platform. But that’s a different interview!
The Snitcher MCP is live. Turn it on in Settings → Integrations → Snitcher MCP or read the setup guide.
