A couple of weeks ago we hosted a RevOps dinner, and something one of the guests said stuck with me. They were talking about a tool they use, and they said something like, "We have to talk to the AI bot just to get our own data out. It's like we're not smart enough to grab the structured data and build our own workflows."

The table laughed, but it was the uncomfortable kind of laugh where everyone recognizes the problem. Your billing platform has your data. You need it. And increasingly, the way you get it back is through some AI agent that the platform built, tuned to their use cases, not yours, and often gated behind an upsell.

That moment crystallized something we'd been building toward for a while at Measure.

How MCP came to be

We shipped our MCP server in April. But the path there started months earlier, and it started with our customers being ahead of us.

What I noticed was that several of our customers had already taken our API and built their own MCP servers as wrappers around it. They were connecting Measure to Claude, building internal workflows, running queries against their billing data in ways we hadn't anticipated. Dockwa, for example, built an app that scans checks, marks invoices as paid, and then pipes reporting into a Slack bot that combines their billing data with their own product data. They didn't ask us to build that. They just did it, because the data was accessible and the API let them.

So the question became: if our more technical customers are already doing this, what about the teams that don't have an engineer to spare? The RevOps person who wants to ask "which contracts don't have a subscription attached?" without filing a ticket. The finance lead who wants to know outstanding collections status without waiting for someone to pull a report.

That's where the official MCP server came from. Not as a feature announcement, but as a natural extension of something we already believed: your data is yours, and your access to it shouldn't be gatekept by us.

Who's using it

Within weeks of launching, customers were already building workflows on top of the MCP server. Some of them had been waiting for it. Others that had already built their own wrappers around our API migrated over immediately.

Right now, teams at Dockwa, Broccoli, Patlytics, Plan-It, Lightdash, and SecondBody are actively using it. And what's interesting is that there's no single profile. It's startups and Series B companies. Technical teams and finance teams. The common thread isn't company size or stage. It's that they all wanted to interact with their revenue data on their own terms, not ours.

What customers are actually doing with it

What I didn't expect was how quickly the use cases would spread across every team that touches billing.

Finance teams are using it for the reporting they've always wanted but were stuck behind our UI roadmap to get. Things like: what's outstanding in collections? Which invoices are overdue from customers above a certain MRR threshold? How much have we collected in the past 30 days? These are questions that used to require pulling from multiple views in multiple tools. Now it's a conversation with your data.

RevOps teams are running consistency checks. Which contracts don't have a subscription? Did we miss setting up billing for anything that closed last month? Which deals are still in draft? It turns out that one of the most powerful use cases isn't fancy automation at all. It's just being able to ask "did we miss anything?" and actually get a trustworthy answer.

Sales teams are pulling deal velocity data. How long did it take from contract creation to signing? How many deals have we closed this quarter? What's our average TCV? These are the insights that usually live in a dashboard someone built six months ago and nobody remembers how to update.

Customer ops teams are handling the operational work that individually takes two minutes but collectively eats hours every week. Generating portal links, processing refunds, updating billing addresses, sending one-off invoices.

The thing that connects all of these is that the data is consistent across every team. Sales isn't reporting one number while finance reports another. There's no reconciliation step because there's nothing to reconcile. The MCP connects to the same source of truth that powers everything else in Measure.

Read-first, and why that matters

One decision we made early was to ship a read-only MCP server first. The reasoning is something I learned the hard way once with Notion, where I prompted something incorrectly and watched in mild horror as it did exactly what I asked, which was not what I meant.

In billing, some actions are irreversible. You can't unsend an email. You can't easily un-cancel a subscription. You can't un-refund a payment. So if an agentic workflow makes a bad decision based on a bad prompt, the consequences are real and sometimes permanent.

Our approach is layered. Right now, the official MCP server is read-only, which means even if someone prompts incorrectly, the worst that happens is they get wrong information, not wrong actions. Then we're building token scopes that give you granular control: this token can read customer data and subscription data, but it can never delete anything. This token can issue refunds but can't cancel subscriptions. You configure the boundaries, and even a bad prompt can't escape them.

If you want full write access, you can still build on our API directly and have the full power of the system. But our official offering is deliberately conservative, because when you're rolling this out to a finance team or a customer success team who aren't engineers, the safety model matters more than the flexibility.

Why this matters beyond a product update

A lot of our competitors are taking the data customers put into their systems and building agentic workflows on top of it. Automated collections, automated follow-ups, automated reporting. Then they use that as a lever for upsells and renewals. Which is fine as a business model. But it comes at the cost of holding the customer's data hostage and then charging them to access it through a specific interface the platform controls.

What I've noticed is that customers don't want to be held hostage by our reporting backlog, and honestly they shouldn't have to be. If we haven't built the exact report they need yet, that shouldn't mean they're stuck. It should mean they have another way to get to their own data.

The MCP server makes Measure more of a data layer and less of a walled garden. Your billing and revenue data sits in a structured, consistent, correct system, and then you connect it to whatever tools your team actually uses. Claude for ad-hoc queries. Custom Slack bots for alerts. Internal tools for customer ops. Whatever makes sense for how your team works, not how we imagined your team might work.

That's the part nobody really talks about with revenue platforms. It's not just about whether the system can generate an invoice. It's about whether you can get your own data without permission.

What's next

Every feature we ship now has to go all the way through to the MCP layer. It's become a horizontal consideration, not an afterthought. As we expand into areas like bank reconciliation and sales commissions, those surfaces extend to the MCP too.

We're also expanding connectors. Right now we're connected to Claude, but the landscape of agentic tools is moving fast, and we want Measure to be accessible wherever your team is building workflows.

And the token scopes work will unlock write actions safely, which is when things get really interesting. Automated collections workflows. Subscription management through support bots. Billing operations that run without a human in the loop, but with guardrails that make that safe.

What I keep coming back to is that conversation at the RevOps dinner. The frustration of feeling like your own data is behind a gate that someone else controls. We built Measure to be the opposite of that. The MCP is just the latest expression of something we've believed from the start: your revenue data is yours, and your ability to use it shouldn't depend on our product roadmap.

‍