The FloConnector blog
Notes from the wire
Field notes on connecting AI to the software businesses run on: MCP, deferred tools, connectors, and the architecture behind FloConnector.
I gave Claude access to my entire business, and filmed what happened
A walkthrough of FloConnector doing real work in real systems: a lead in Gmail becomes a ServiceM8 job, a stale CRM pipeline gets chased and pushed through to a work order, and a supplier remittance marks off a month of invoices. Including the two things it got wrong.
Deputy + AI: 174 tools, and the pay run stops being a surprise
Deputy runs on a connector we build and maintain ourselves, with 174 tools across rosters, timesheets, leave, awards, people and locations. Ask what the fortnight cost while there is still time to do something about it.
MCP Apps: fifty connectors, one widget
MCP Apps is the first official extension to the Model Context Protocol: a server can now render its own interface inside the conversation. Here's why a platform sitting in front of 50+ vendors should build exactly one of them, which one we picked, and what the protocol taught us on the way.
AroFlo + AI: 72 tools, and an answer that isn't quietly a month old
AroFlo runs on a connector we build and maintain ourselves, with 72 tools across jobs, quotes, invoices, bills, purchase orders, scheduling, timesheets, inventory and assets. The interesting part is what we had to do so the answers are the whole answer.
Fergus + AI: 86 tools, and the quote goes out the same night
Fergus runs on a connector we build and maintain ourselves. 86 tools that follow the shape of the work rather than the shape of the API: an enquiry becomes a quote, the quote becomes a job, the job splits into phases that carry the labour and the materials. Including the part integrations usually skip.
ServiceM8 + AI: 167 tools, and it can read your job photos
Our ServiceM8 connector went from 28 tools to 167, and it can now look at the photos your techs take on site: read a serial off a nameplate, read a meter, check the work was finished. Here's what you can actually ask for, with examples.
Code mode needs a sandbox. Query mode doesn't.
Context engineering for MCP has two named answers: deferred loading for too many tools, code execution for too much data. Code execution buys its savings with an agent sandbox. Here's the third answer I built FloConnector on instead, why I think it's the right default, and where it loses.
What is an MCP server? A plain-English guide
An MCP server is the piece that lets an AI like Claude actually do things in your other software: read a spreadsheet, send an email, raise an invoice. Here's what that means, how it works, and why you probably shouldn't build one yourself.
How FloConnector keeps 50+ connectors out of your context window
Loading every tool a business might need costs ~72K tokens before the model reads a word. Deferred tools flip that: the model pays only for what it reaches for. How it works, why it isn't part of MCP, and what a server can actually do about its own context cost.
Your AI never sees your passwords (and it never should)
Connecting an AI to the software your business runs on means handing over the keys to your inbox, your CRM, your calendar. The one thing that should never happen is the AI ever holding those keys. Here's the credential architecture that keeps them out of the model's reach.
Skills or MCP? You're asking the wrong question
The 2026 debate frames Agent Skills and MCP servers as rivals: pick one. They're not rivals. MCPs are verbs; Skills are playbooks. The interesting systems use both, and understanding why tells you a lot about where a hosted connector layer fits.
More connectors, worse agent: the tool-overload trap and how to escape it
There's a counter-intuitive failure mode in agent design: adding tools past a point makes the model less reliable, not more. Here's why it happens, the numbers behind it, and the progressive-disclosure pattern that lets a workspace run dozens of connectors without paying for it.