5 Things You're Doing Manually in Karbon (and How AI Can Do Them for You)

Beau — Partner, Growthwise

06:18What an MCP actually is

I saw earlier in the chat that someone briefly went through what an MCP server was, so I wanted to expand on it. MCP stands for Model Context Protocol. It was released by Anthropic on the 25th of November 2024, and they made it an open standard. What that means is it doesn’t matter whether xAI uses it, OpenAI uses it, or anyone else uses it — it’s open, so anyone can use that particular technology.

The reason they created it is they wanted to let agents — or even you yourself — interact with APIs without having to fully understand code bases. If you’ve ever tried to do any coding, or even vibe coding, you’ve probably noticed that to make things work you really need to understand a lot of terminology. To tie it in, I’ve got Karbon’s API documentation here for getting a list of work items. If you look at it now, you’re probably confused — that was my experience about a year ago. You read through it, you give it to Claude or to OpenAI and say “explain this to me,” and you’re probably still confused.

The whole idea of MCP is to make these queries doable in plain English. Instead of having to understand what “get” means, what “post” means, what “delete” means, you can just say “give me my work items” — a really simple language front end to what an API is actually capable of.

08:37Reading the MCP: tool names, descriptions, and the protocol

Here’s a good example of the English-language translation of an API call. This was vibe coded for me to pull data out of Ignition’s MCP server. We’ve got something called “list agreed services” as the name — that’s what we’d call the tool call, telling the API what we want. But notice the description is something you and I can read. We don’t have to get super technical; we can just read it and understand what it means.

When you ask your LLM “can you tell me my agreed services?” you don’t need to be super specific. The model interprets the request — that’s the “model” in Model Context Protocol. The “context” is the c part: the context of the request that’s been made. “Protocol” is the last part, which is basically the handshake that says what you are and aren’t allowed to do. With certain MCP servers — for example, Xero’s connector in Claude, which is technically an MCP server — it’s read-only. It’s limited in what you’re allowed to do. That’s what we mean by the protocol: the handshake defining what you can and can’t achieve.

10:01Thing 1 — Cleaning up contact data from an export

Let’s jump into Karbon. The first thing I want to talk about is what we’d just call manual interaction. I’m on a contact screen, and I’m going to download the entire contact list. It comes out as a spreadsheet.

If you’re not used to using an AI tool, you can still leverage the exports out of Karbon and drop them into an AI tool. So let’s go into the downloads folder and query the data: “tell me who does not have a mobile number in my contacts.” When you’re doing system setup, one of the biggest issues people have is clean data. You might have XPM linked in, FYI Docs linked into Karbon — this is a good way of doing a data sanity check.

You can see Claude separating it out, and because we’re using a higher model you can see the scripting happening behind it. People ask me, “how do I know what the AI is doing?” — well, you can see the steps it’s taking to generate the result. It flags what it found, then narrows to what I actually care about. It found one mobile number present — that’s my own number, so I’m doxxing myself a bit. We’ve got 157 contacts in Karbon, so if you want a quick data sanity check across email addresses, primary phone numbers and so on, that’s a really good place to start.

12:54Karbon’s built-in AI: email, contact and work summaries

Outside of exports, there are things already in product in Karbon. If you’re already a Karbon user this is the most boring part, but if you’re not, it’s worth seeing.

Here’s an AI-generated test email — it’s quite long. Karbon has a button at the top that does an AI summary of that email. We’ve gone from a massive block of text down to a four-line summary. If you saw something important come through and you don’t have time to read it in depth, you click that button and get the summary.

You can do the same on a contact or on a work item. On the contact timeline you can click “show summary” and it does a conversation summary of everything on that timeline. Or you can do it on a particular piece of work — say a team member’s gone on holiday and you need to familiarise yourself with a client or a job quickly. You jump in, click the button, get a quick summary, and move on. On a work item the summary can be regenerated if more emails get added.

The last built-in one is in Karbon’s timesheets. Once you’ve interacted with a piece of work, Karbon uses AI to suggest what you should be doing with that work — a suggested time entry.

15:51Thing 2 — Building a time dashboard from a timesheet export

We saw we could give Claude a data export, so the same applies to work. You can download a work export, and I’ve got a timesheet export here we can use as an example.

In Cowork I’ll say: “using this data, let’s generate a dashboard showing the breakdown of time based on work types.” When you do this kind of query, you want to look at how the data is actually structured first. I said “work type,” but when we look at the spreadsheet the column is actually called “task type.” To save on tokens and be more specific, I’ll say “let’s break the time down based on task types instead” — it happens quicker because it’s not trying to interpret what task type versus work type means.

You’ll see it start preparing the session and generate the dashboard, and you can look behind the running command to see how it’s interpreting the data. With the Opus 4.8 model it really tries to keep track of everything. We end up with a dashboard showing total hours, overall time entries, and the top task type. I can click on any user and get a breakdown. As Trent mentioned, you do get bugs — here we’re missing the “hours by task type” breakdown, so you’d just re-prompt Claude: “you’ve done this, but we’re missing the hours by task type breakdown,” and it’ll likely fix it.

The point is: if you’re not familiar with an MCP server or working with agents, you don’t have to be. If you can get data out of a system, you can use it to generate information like this.

21:21How we built a custom Karbon MCP from the OpenAPI spec

Now let’s talk about what we’re doing with an MCP server. If you’re a Karbon user you’ve probably seen they’ve been teasing an MCP server. They haven’t released it yet — I have it on good authority it’s going to be released probably within the week — but I don’t have access to it.

What we’ve been able to do is use the fact that Karbon publishes an OpenAPI specification. This is the specification behind their API, and if you look at the descriptions they’re very similar to what we saw in the Ignition MCP server. We can give that OpenAPI spec to Claude and tell Claude we want to make our own custom MCP server based on it. That’s what we’ve done.

If I look at the connectors in Claude, I’ve got three turned on: the Karbon API using our custom-created MCP server, Maxo (our phone provider at Growthwise), and Gmail. So let’s look at what you can do when different systems interact.

22:54Thing 3 — Reassigning work in plain English

In Karbon I’ve got 116 work items. Dolly Parton has four work items and Les Claypool has six. In Claude I’ll say: “Dolly’s going away next week singing, can you reassign all of the work items to Les?” Notice I haven’t said anything specific about Karbon — I just have the connector set up.

You can see it calling the tool call — converting that English into an API call, getting all the users, working it out. It confirms Dolly has four work items and reaches for the patch tool to reassign them. Here’s a good example of a downside: Karbon’s API supports “patch,” but patch only lets you change very specific things on a work item. It figured that out on its own and switched to using a put request instead, and the change goes through in the background.

A question from the chat — will Karbon’s MCP allow read and write? The initial release will be read-only, but I’ve been told a longer-term release will support write. A lot of vendors do this: they don’t want things to be destructive, so they release with interpretation-style read access first and expand over time. And on whether you can do this in Copilot or Cowork — yes, because MCP is an open standard, it’s not limited to whichever AI tool you use. The end result here: all of Dolly’s work transferred to Les off a single request.

27:23Thing 4 — Turning an email into Karbon work items

We’re also connected to Gmail. There’s a work request email in this test account for Vinyl LLC — that’s the one we summarised earlier. In Claude I’ll say: “can you see the email about Vinyl LLC? Read it and make some work items based on the email, then assign it to Liz.”

It finds the email — Trent’s asked us to do bookkeeping reconciliations and a range of other tasks — and then it calls the Karbon tooling. We gave it a plain-English request, it went out to Gmail, and now it’s going back to Karbon. I haven’t created a Vinyl contact in Karbon yet, so because it understands how the API works, it flags: “Vinyl LLC isn’t set up as a client in Karbon yet — what do you want to do?” I say make it a new organisation, and it pulls nine work items out of that very long email. You’ll also get permission pop-ups for the tool calls — you can choose “always allow.”

A note on security, since that came up: whenever you use these tools, read the terms of service. Everything I’m showing today is 100% demo data, so I’m not being as cautious as I normally would. Don’t assume that paid means safe. Claude’s personal plans, by default, don’t save a lot of data — but if you give feedback with a thumbs up or thumbs down, on the personal plans they have the right to retain that data for up to five years, which is a bit scary. On team and business plans that window shrinks dramatically and they don’t train on your data by default. So “how safe is it” depends on the plan you’re using.

The work all gets created — the Vinyl contact appears as created a minute ago, and all nine work items show up against the client. My suggestion: lean on your workflow systems (like Ignition) for what they already automate into Karbon, and lean on AI for the things they don’t. That way you use your AI budget wisely instead of burning through credits.

33:47Thing 5 — Texting a client straight from Karbon data

Earlier we saw The Firm client is the only one with a mobile number in Karbon. In addition to the Karbon connector, we’ve also made a connector for a phone/SMS system. If you’ve got something like Twilio or Vapi — or other connectors that allow outbound messaging — there’s no reason you can’t make Karbon interact with that too.

The aim is to pull data out of Karbon, act on it, and send messages back. So: “The Firm is hosting a talk today — can you text them and just say good luck?” You’ll see the tool calls, and I’ll hold up my phone. MCP servers aren’t always succinct, so it initially went looking for the context of an “event” in Karbon, which is irrelevant. On a live demo you sometimes have to guide it a bit more — I can give it the organisation ID so it looks up the mobile number on that contact. Shortly after, a message pops up on my phone: “good luck with everything,” sent from our mobile number, with the SMS cost shown because our SMS service charges per message.

While we’re here — “can you add a note to their timeline so others know I sent that SMS?” The note wasn’t on the timeline before; after the request, you can see the back-and-forth write it in.

On data sovereignty and retention: there are agreements you can have with some AI providers for data sovereignty and what’s called zero data retention. With a ZDR agreement, once the provider has processed your data it’s deleted — there’s no reference to it at all. So there are mechanisms to treat everything more securely.

39:15Building the MCP server: a look under the hood

Probably the best way to explain the build is in VS Code. The Karbon MCP server I had created has a script file behind it — I used Python for the programming language, and it explains how it does the interactions back and forth.

OpenAPI — not OpenAI; they’re one letter apart and I used to get them confused — is a specification that explains how to build to an API. That’s the specification you give Claude to say “can you generate an MCP server for me?” Everything in this folder is Claude-generated as its own MCP server, which you then add into Claude as a manual task.

Karbon’s OpenAPI spec is actually available on their GitHub. You can copy the whole thing, open a new chat in Claude, say “I’d like to make an MCP server based on this OpenAPI specification,” paste it in, and let it go. It might ask clarifying questions. Not every vendor publishes an OpenAPI spec — a lot do, because it makes their API easier to work with — but for example Ignition has their own MCP server without exposing their OpenAPI spec. So in some cases you can do this and in others you can’t.

For most of you, my honest recommendation is to wait — Karbon’s own server won’t be long. Note that their spec exposes 66 different capabilities, but the official release will likely be limited because they only want things to be readable at first. There are also security risks to building your own, so I wouldn’t recommend everyone does it — you’re getting a sneak peek of what you’ll soon be able to do.

42:27Why this is more approachable than it looks

Even though some of this seems more advanced — and in some regards it is — Claude and your AI systems make it a lot easier to comprehend. You don’t need to know everything that’s going on, and this is much better for internal use. You’re not publishing this to hundreds of people; you’re building internal tooling. I vibe coded against the Karbon API the other week, and even I managed to figure it out inside an hour — and I’m not a technical person, though I do spend a lot of time on it.

On token burn — someone asked about Sonnet versus 4.7. It depends on the task. The lazier you are with a prompt, the more tokens you tend to burn, because the less data you give the model the more work it has to do. A downside of MCP servers is that every request has a token input and output cost. You can use Opus 4.7 for this; you don’t need 4.8 at all. Over this session our usage went from 3% to 6% on the Max plan — we haven’t done anything heavy. If I said “make 300 work items,” you might see it jump to 20–25%. It comes down to using the model appropriate for the task: if it’s just reading a small email or working off a dataset you’ve provided, you don’t need a super-heavy model, because most of the processing work is already done in the file you gave it.

45:22Where this is heading — agent-to-agent and human-in-the-loop

A2A stands for agent-to-agent (or application-to-application). So far we’ve interacted as humans saying “can you do this task for me?” The next iteration is this: you might have Vinyl doing the recording and transcription that comes into Karbon, and your Claude monitoring that — “I can see that meeting; from it the follow-ups were to draft an email and do these things.” The agent-to-agent layer is one agent seeing that data and taking the next iterative step on your behalf.

That comes down to how much you’re willing to trust it. The point where you want to stop is up to you — “I’m okay for it to draft the email, but I don’t want it to send it.” That’s what human-in-the-loop means: you let the agent go up to a certain step, then a human approves the final step before it moves on.