Field Notes
Why we built an MCP server for Neon Deer
Lately, it feels like half my conversations with Attio customers involve using it as a headless CRM, whether they call it that or not. They're working through Claude and other AI assistants, looking up records, making changes, and answering questions without ever opening Attio.
It's made me rethink how we're building our own platform.
We've built tools that extend Attio, from duplicate detection and merging to more advanced workflow automations. They work well, but they also introduce another product to learn. Users still need to figure out where settings live, how to configure things, and where to go to see what's happening.
That started to feel like unnecessary friction. If someone is already working with their CRM through an AI assistant, why should they need to switch to another interface to use our tools? Why couldn't they describe the rules they want, have an assistant configure them, and check the results as they go?
We think of Neon Deer as an extension of Attio, not a separate system. We're working with the same records, workflows, and data, so the experience should feel connected too.
That's what led us to build out our API and MCP server. We wanted people to be able to use the platform through the tools they're already working in, not just through another web interface.
From configuration to day-to-day use
MCP, or Model Context Protocol, provides a way for AI assistants to interact with external tools and services. For us, the interesting part wasn't just making information available to an assistant. It was figuring out how much of the actual work we could make accessible.
Much of the effort involved in using our platform happens before someone gets any value out of it. They need to configure matching rules, populate lookup tables, set up automations, and understand how everything fits together. Once it's running, there are still results to review, settings to maintain, and occasional problems to investigate.
Take territory routing as an example. Today, you can configure a lookup table that maps territories to account owners, then use those assignments in an Attio workflow. Through MCP, you could ask an assistant to create and populate that table, make adjustments as your team changes, and check the results. With an existing Attio workflow selected, the assistant can also schedule records into it and monitor the pending runs.
Or consider Email Notifications. Instead of navigating to the app to investigate a failed notification, an assistant can look up delivery results, help identify what happened, and make permitted configuration changes.
Duplicate detection works similarly. An assistant can configure matching rules, run scans, review potential duplicates, and help prepare merges.
None of this requires learning where we've put a particular button or configuration screen.
That doesn't mean the web app is going away. There's plenty of value in having a visual interface, particularly when you're reviewing large amounts of data or making more complicated decisions. Some administrative settings also remain available only through the web app. But I don't think it should be the only way to use the platform.
Working alongside Attio's MCP
One of the things I like about this approach is that we don't need to recreate what Attio already does.
Attio has its own MCP server, which gives assistants access to the underlying CRM. Our MCP server handles the additional functionality we've built around it. Connect both, and an assistant can work across the two without you having to think much about which system is responsible for what.
Duplicate detection is a good example of where this becomes useful.
Our platform handles the matching rules, scans, AI assessments, review decisions, and merge planning. Attio's MCP can retrieve the current values of the records we've identified, giving the assistant additional context when reviewing a potential duplicate.
You could ask something like:
Show me the potential duplicate companies from our latest scan, along with any existing AI assessments. Use Attio to compare the records in the set I select, then help me prepare a merge plan. Show me what would change and what the backup covers, but don't execute anything.
The assistant can pull the duplicate sets from Neon Deer, inspect the current records through Attio, and prepare a plan for review once you've chosen which records to merge and which to keep.
Attio already supports merging records through its own MCP server. What we're adding is the surrounding process: identifying potential duplicates using custom rules, assessing them, reviewing the proposed changes, and providing backup-based recovery options.
The larger point is that these tools can complement one another. We'd rather build on the functionality Attio already provides than duplicate it just to keep someone inside our own product.
Giving assistants access without giving up control
There's also a fairly important distinction between letting an assistant help with something and letting it do whatever it wants.
Personally, I wouldn't fully delegate merge decisions to AI. I'm comfortable letting an assistant find potential duplicates, compare records, and propose what should happen. I'm considerably less comfortable giving it unrestricted permission to merge thousands of records without reviewing the results.
Other people are more comfortable with automation, and that's fine too. We wanted to support both approaches.
That's why we've separated permissions for reading duplicate data, preparing merge plans, and executing them. An assistant can investigate records and prepare a proposed merge without having the ability to execute it. Your organization's settings and the connection's permissions determine whether the assistant can execute a merge plan. Otherwise, someone runs the plan in Neon Deer. The permissions guide explains how to choose that access.
It's also important to remember that these permissions apply independently to each connector. Restricting merge execution through Neon Deer doesn't prevent an assistant from using Attio's own merge action if it has permission to do so. Telling an assistant not to change anything is useful, but it's no substitute for configuring permissions correctly.
We've also invested heavily in unmerging records, because even carefully reviewed merges can turn out to be wrong.
Attio has no native unmerge, so Neon Deer uses a pre-merge backup to reconstruct the records. It can restore supported attribute values, reconnect references from other records, and restore captured attribute history where Attio permits it, including previous values and their effective dates.
The aim is to restore a record's place in the CRM, including its relationships, rather than recreate an isolated copy.
There are limits, though. Reconstructed records receive new IDs, some system-managed fields can't be restored, and certain related items still require manual follow-up. Unmerging this way isn't an exact undo, which is another reason I prefer reviewing a merge before it happens.
We've documented those limitations in more detail in our unmerge guide.
Where we're going with this
We're still early in figuring out exactly what that experience should look like, and I expect we'll learn quite a bit from how people actually use it.
For now, Neon Deer's MCP server is available by invitation in alpha, with support for Duplicate Detection, Automations, Email Notifications, and shared platform functionality.
You can find the setup instructions here, or get in touch if you'd like to try it.