Home Office MCP: Giving My AI Tools Somewhere to Connect

AI tools have a lot more integrations now than they did a few months ago. Things moved so quickly that some of the services I couldn’t connect to ChatGPT earlier now have much better options.

But at the time, I had a much simpler problem.

I was using a project tracker that ChatGPT couldn’t reach through the integrations available to me. I could ask it to help plan work, review a document or prepare an update. Then I’d still need to open the project tracker and do the next part myself.

I remember wondering, “How do I get my ChatGPT account to work with this?”

That question eventually became Home Office MCP.

I wasn’t setting out to build a universal AI platform. I wanted useful tools to talk to the services I already used, without leaving those services wide open. It started with one integration. As usual, “one” turned out to be an optimistic estimate.

Plane was the first real connection. I used a Raspberry Pi 4, deployed the existing Plane MCP server and connected it to ChatGPT through a secure tunnel.

The early proof was straightforward: could ChatGPT list actual projects and work items, and could an approved update reach Plane correctly? Then, could the setup survive a reboot without me having to put everything back together?

By 19 July 2026, those checks had been documented as passed.

That established something important for me. The AI didn’t need a custom copy of every project’s data. Plane would remain where that information lived. I needed a controlled bridge that could let ChatGPT use it.

One bridge was useful. I soon wanted a few more.

I had a support mailbox for Silk hosted through PurelyMail. I wanted to read messages, prepare drafts and handle certain mailbox actions through the same AI workflow.

I could’ve kept a separate connection for every service, but that meant repeating the setup and managing a growing list of independent tools. So I helped define a small MCP hub instead: one place ChatGPT connects to, with separate connector services behind it.

The first hub paired the existing Plane connector with a new Silk Email connector. Each group of tools kept a recognizable name, and the hub could discover and combine their available operations rather than maintaining a second handwritten copy.

On 20 July, we had the hub and email path running through the Pi, with live ChatGPT checks. The original direct connection had grown into something reusable.

And email taught us a lesson almost immediately: a message being “sent” and every step after sending succeeding aren’t necessarily the same thing.

Later we added a tasks integration backed by OpenProject. I wanted a stable way for AI tools to read and work with home-office projects and assignments without depending on product-specific names everywhere. The underlying project system still enforces membership and permissions.

Penpot was a different kind of challenge. An early route depended on the design application’s browser/plugin state and a workstation bridge. It wasn’t a good fit for a self-hosted system I wanted to keep running independently.

The eventual approach was a bounded direct adapter on the workspace server. The hub exposed reviewed design operations through a fixed contract, and the adapter handled the application-specific work. Reads, exports and later carefully constrained design changes could use the same general connection without turning it into a generic remote command tool.

That distinction matters. An AI assistant being able to help edit a design doesn’t mean it should receive arbitrary database access, shell execution or whatever API method it happens to imagine.

Email provided the clearest early example. Suppose the provider accepts a message, but saving its copy in the Sent folder fails. If the integration reports that as a simple send failure, an assistant might retry and send the same message twice. Deleting one message also mustn’t accidentally empty an entire folder.

Those were real safety issues recorded after the first release. We corrected and tested them, then qualified a controlled read, draft, send and targeted deletion. On 20 July, the version 0.1.1 acceptance record marked those steps as passed.

With Penpot, the equivalent problem was uncertain writes or changes made against an old file revision. We used narrower allowed operations, revision checks and repeatable request identities rather than assuming a second attempt would always be safe.

The wider lesson: when software can take action on your behalf, the most important behavior isn’t only what happens when everything works. It’s what happens when a request succeeds but the response gets lost, or when one service isn’t available.

I’d keep reducing the manual work needed to check what is deployed, whether the live tool list matches the source and what to do when a service goes down. The same applies to clearer operator documentation and a cleaner way to introduce new approved tools without disturbing existing ones.

I also don’t want to add a new connector simply because a connector is possible. I’d rather start with a real task that needs it, decide the narrowest useful interface and prove it against the actual service.

Looking back, I asked how to make ChatGPT reach one missing tool. Now I have a little integration hub that comes with release checks and operating guides.

That’s probably more infrastructure than I imagined when I asked the question. But it lets me spend more time working with the tools I chose and less time wondering how to connect them.