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, all jokes aside, 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 pursue that for a while. My plan initially was to refresh my skillset and then find a way to leverage that towards a career in data-driven journalism. The truth is once things got going I just really enjoyed coding. It’s so much more collaborative than the world I was coming from and things just clicked for me from then onwards. Funnily enough the humanities background has come in handy along the way because it helps me be a better communicator which, surprise surprise, turns out to be quite a differentiator among engineering folk.
Before we carry on, what is an MCP?
When LLMs came along people realised these are essentially a new class of software users with their own set of needs. MCP is an attempt to make software protocol that optimally services that particular class of users. Sure, agents could interact with our product through browser automation or by purely using our API and they could get many tasks done in theory. But UIs are optimised for human understanding and are very inefficient for agents, whereas an API is optimised for programmatic consumption which has different security and efficiency tradeoffs.
An MCP allows you to provide an agent with a set of tools, and the context needed to combine those individual tools into powerful workflows so our users can come to their agents with open questions and get actionable insights out. Given only the tools and no context agents would have to do research on how Snitcher works to get there, but MCP allows you to co-locate all that knowledge with the tools so it can start moving immediately. What do we think an ideal workspace configuration looks like, what are various playbooks that we recommend that allow our advanced users to get the most value out of the product. All that insider knowledge is baked in from the start where your agent needs it.
So, who decided we needed an MCP?
Look, the AI hype cycle makes it hard sometimes to be clear eyed about whether something is a buzzword you won’t ever hear about in six months or a permanent fixture of software development going forward. The thing that tipped it for us was the experience of getting more out of products we were already using when we would start using the product via MCPs.
At some point we realised if we are to be successful we need our product to meet people where they already are. Many of our users spend their workdays inside of Claude, Codex and other agent platforms. Even Slack can consume MCP natively as well now. So this quickly moved from a nice to have to being a table stakes feature. 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 be the meat proxy doing 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.
Walk me through how it came together.
This was a really fun thing to work on because it’s essentially a new class of software product, right, and one that isn’t intended primarily for human consumption, so there aren’t many clear directives out there that tell you what ‘good’ looks like in this category. The result is you have to define that for yourself.
The flipside is that you can give Claude a prompt and it will give you some implementation in about a single sitting. It might have gaping security holes you might have never thought of, or completely novel ways for users to abuse your product in costly ways, but on the surface it looks like it works.
We resolved this by focusing on internal tooling first. This allowed us to work on some of the tools we understood best, to be able to talk to our users (colleagues) directly, and to ensure that we had good observability tooling set up around this so we were able to see where things were going wrong and iterate quickly. Once we were seeing our non-technical colleagues being able to onboard themselves onto the MCP and get real value out of it we started focusing on MCP for end users.
Nobody ever sees your work, though. So what were you actually designing?
Well, you can break our product up into a suite of MCP tools in essentially infinite ways. The tradeoffs you choose in this process determine if an agent is able to complete a task in the first place and if so at what cost in time and tokens. One thing we learned is that Claude will make all sorts of assumptions about the relationship between the data it gets out of your tools that might be wrong and this can lead to very inefficient sessions.
A second learning was that the agents will sometimes come up with all sorts of smart ways to get actionable insights out of your data by using our segmentation filters in ways humans might not, and we needed to nudge the agents via the MCP to turn those filters into permanent segments so the user can benefit from this long term. Adding the right annotations and ambient context to the tools allows an agent to understand when to suggest making these kind of updates.
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 should require explicit user consent. 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.
But then you don’t want to go too far with the guardrails either. Eventually you want to be able to run powerful agentic workflows and for humans to just get the end product. So finding the balance there is a bit of a journey of discovery, but it’s still better to provide guardrails and give people ways of disabling them when they are ready rather than vice versa. Luckily so far I have not heard any complaints of users having inadvertently fucked up their workspaces using the MCP.
How do you test something with no interface?
The lack of an interface is not really the problem. In the end these are just programs you can unit and integration test along similar lines to an API. But that only gives you insight into correctness, not usefulness. The more frustrating part of building this is that we can only see what tools users are calling, but not the question they asked their agent that led to those tool calls. In some cases the intent is pretty obvious but sometimes we see unexpected combinations of tools being used where you think, hey, this might be a use case we might want to optimise for. You don’t see what people are actually asking their Claude.
In the end the solution is still and will always be to talk to our users. As an engineer with intimate knowledge of our platform it can be hard to see it from a new user’s perspective. Even my own instance of Claude has so much product knowledge in its memory base (not to mention codebase access) that it is not a reliable tester of the MCP tools. It’s far better at finding workarounds (or will sometimes just make a sneaky db query on the side).
The upside is we built in a submit-feedback tool that lets agents ping us directly if anything is missing, broken or confusing and we get regular direct feedback through this. This makes it almost a self-improving product by now.
What’s the dumbest thing you watched it do?
There was a period where our filter logic was not correctly annotated, which led to agents going in loops trying to get data out of the product, and eventually just pulling unfiltered datasets out, writing them to a file and doing filters on their end. But mostly it is just people finding use cases that surprise us.
Like, there was this dude who did 700 tool calls in a session. We paused his access because we wanted to make sure he was not malicious. Turned out he was a completely legitimate user, just building himself an outbound list in a rather token inefficient way. One side effect of those calls was it was burning through our enrichment budget with some third party providers because usually those all take individual clicks in the UI, 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.
But if you want a proper answer: ask it to help you squeeze the most out of your workspace setup. There are a thousand ways people get value out of Snitcher and often people come in with one or two set ideas what to do, and then they miss all sorts of capabilities we have. The MCP provides a lot of this context so it is a great way to ensure you get maximum value out of the product.
This is the case even more because an MCP user probably has an MCP set up for their own CRM as well, so the agents can then intermediate between these two services. What data exists in Snitcher that is useful to have in the CRM → set up a custom mapping. What CRM data is useful for doing more advanced segmentation? 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?
One of the things I am really excited about is making agents first class citizens in our product. Agents are terrifyingly good at moving work forward. By giving them the tools they need to keep it moving we hope our users can discover all these new avenues of squeezing value out of Snitcher.
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 from the Snitcher MCP integration page, or read the feature rundown first if you want to see everything it can do.
