How I Connected Kitchen.co to Cursor Without Wasting Tokens

I run client work in Kitchen.co (opens in a new tab). Folders, boards, tasks, conversations, clients, invoices. It is a strong all-in-one CRM and invoicing setup, and I white-labelled the workspace at web.dimyosman.com (opens in a new tab), so clients log into my brand instead of a generic SaaS screen. That part was already fine. The annoying part jumping between the Cursor and Kitchen and giving AI context from CRM.

I live in Cursor, one workspace per project. Kitchen held the record of the job. Cursor held the build. I was the copy-paste layer between them: tracking milestones in one window, writing in another, then copying client comms by hand so the agent had context. That bounce was the work. I wanted the agent to see Kitchen without me retyping it.

Would it not be great if there was a way to connect Kitchen with Cursor, and run it all through one environment?

The gap was the bounce, not the CRM

I did not need a new CRM. I needed the editor to stop treating Kitchen like a second desk. If a website should connect to a CRM so a form becomes a record, the editor should connect to the same CRM so I am not retyping the record. I wrote about the website side of that in how a website should connect to a CRM. This post is the other half: how I hooked the workspace I already pay for into the place I already write code.

So the question was not “which AI CRM should I switch to.” It was whether I could stay in Cursor and still create a folder, move a task, read a conversation, or check an invoice without opening Kitchen for every tiny action.

There was no official AI integration

I looked for a Kitchen-native way to let an agent read and update the workspace. There was not one. Kitchen still does not ship an official MCP server or an agent product. What they do ship is a serious public API, documented at developer.kitchen.co (opens in a new tab). MCP, if you have not had to care yet, is just a way for an editor like Cursor to expose tools an agent can call: create this, list that, send this request. The API lets another application request data or perform actions without using the normal interface. That was enough to start.

I talked with Stefan Grudov, Kitchen’s founder, before I built any of this. Over the years I have sent him a fair share of ideas for improving Kitchen: things I thought it was missing, UI bits, workflows. Some of it landed. Some of it did not. I also had a chance to jump on a call with him. We talked about Kitchen, and a lot outside of Kitchen too. I really appreciate how open he is. Not every founder gets on a meeting with some random guy dumping crazy implementation ideas into support chat. Stefan did. He is a really great guy for that.

Once it was clear there was no official MCP, I built one myself on the public API. It is not affiliated with Kitchen.co, 2create.io, or their affiliates. You bring your own workspace URL and API token. The extension does not sell Kitchen accounts, and it does not replace Kitchen’s own product.

First tests went further than expected

I built the connector in Cursor with an AI coding agent. I pointed Cursor Grok 4.6 at Kitchen’s public docs, kept the work in a real workspace, and tested against live folders, tasks, invoices, and messages.

The first tests were better than I expected. Creating a folder, listing boards, reading a conversation, moving a task: the agent could do the work I had been doing by bouncing between UIs. That cut a lot of friction. Workflows that used to mean two windows and a copy-paste started to run from Cursor. That was the point. The CRM stopped being a second desk.

Then I sent it over to Stefan and we briefly chatted about it. We agreed to catch up later. They are really busy getting major releases out in the following weeks. He also said they plan to build an official MCP in the future as well, but that this one looks great.

Once that worked, I did the obvious next thing, and this is where I made it worse. Kitchen’s docs cover a wide public surface, so I wrapped more of it as named MCP tools. Folders, boards, lists, tasks, clients, invoices, conversations, then the rest of the documented public paths. Coverage felt complete. By mid-August the connector advertised on the order of 199 named tools, each with a full JSON schema. I originally thought that was the finished product. Then I used it for a few days and the small jobs got expensive.

Small actions were paying for the whole menu

After a few days of real use, the agent took several seconds to start even simple jobs: create a folder, flag a task, list invoices. Token use on those turns was out of proportion to the action. I looked closer.

MCP’s tool list is not an index. Each tool arrives with a name, a description, and a full input schema. Chat clients then resend that menu to the model on the next turn. If you advertise ~199 schemas, you pay for ~199 schemas, even when the job is one title and one board id. I was burning tokens on jobs that should have taken a second.

Kitchen also has no public endpoint that returns a live catalog. There is no OpenAPI dump you can query. GET /api/openapi.json is a 404. So I was not pulling Kitchen’s schema from Kitchen on every request. I had built the dump myself, then I was feeding it to the model myself. That is a slightly embarrassing realization once you notice it. I did not think it through. The second you feed every API capability in as named tools, you load the JSON with all of it. The waste was mine, not Kitchen’s. That is what vibe-coding an extension gets you when you are also in the middle of multiple client projects.

Connecting two systems is step one. Step two is deciding what the agent needs in front of it all the time, and what it should look up only when the job actually needs it. I would have saved myself a round of work if I had treated that as part of the first build instead of a cleanup after the token bill showed up.

Keep the daily tools named, put the rest in a resource

The fix was a split, not a smaller product. I did not want to throw away coverage. I wanted creating a folder to stop chewing through webhook schemas, embed schemas, and file-upload completion schemas that I was not using that turn.

I counted the calls I actually make in day-to-day work (I mean, Grok did). It looked at a couple of days of usage, then we curated the most-used ones:

• Folders, boards, lists, and tasks
• Labels and members
• Clients and invoices
• Conversations and messages
• A whoami check, plus a generic request tool for everything else

That hot path is 27 named tools. Those keep full schemas, because the agent uses them constantly and needs the arguments right. Everything else stays available, but not as 170 extra schemas on every turn. The compact public-path map lives as an MCP resource. The agent reads it when it needs a less common endpoint, then calls a generic request tool with method and path. A second resource holds the full catalog if the index is missing or a path fails. Neither resource is fetched live from Kitchen. Both ship with the extension, built from the public docs.

That cut the default menu down and sped the workflow up. The rare paths are still there. They are just not sitting in the context window while I tick a task.

Start from daily actions

Wrap what you actually do every day. Do not start from the API table of contents.

Use the public API

Kitchen’s Bearer API is the supported surface. Do not scrape the web UI or copy session cookies.

Keep tokens local

The workspace URL and API token stay on your machine. You are responsible for what the agent does with them.

Measure a small job

If creating one folder is slow or expensive, the menu is too big. The dump is the first place to look.

Prefer an index for the rest

A compact path map, read on demand, beats 199 schemas in every prompt.

This is unofficial

This is an unofficial extension. Kitchen confirmed their official solution is coming soon, but in the meantime, feel free to use this one.

Final takeaway

Kitchen.co is a great all-in-one, a CRM, client portal, resource sharing, and invoicing. If missing MCP was your blocker, consider that unblocked.

I use this every day. It accelerated the work, and it took a lot of unnecessary load off navigating UIs across several workspaces and Kitchen: figuring out what is what, where it lives, and why. Now I tell the agent to look at this folder, or that board, and get on with it. A small SKILL.md in each workspace, with instructions for that project’s Kitchen setup, made the whole thing even better. The agent already knows the map.

I still use Kitchen.co as the workspace. I still white-label it. I still build in Cursor. The unofficial MCP is the bridge that gives me a unified workflow, and one less friction in getting the work done. Creating milestones, flagging tasks as they get done, reading and acting on client communication and resources, even the boring chores like filling in business details and creating invoices: that is a message away. It becomes an afterthought, and that is amazing.

Frequently asked questions