I run a small consulting shop. The failure mode is never a dramatic one. It is a thing that quietly stopped moving three weeks ago and nobody noticed because it still looks fine in the task list.
Task lists are bad at this. A task sitting in "in progress" looks identical whether it moved yesterday or in June. The signal that it is actually dead lives somewhere else: the client attached to it has not been contacted in two weeks, the invoice tied to it is still open, and the last note on it was a question nobody answered.
That is three different systems. So I built the thing that reads all three at once.
What the query actually does
Founders OS is an open-source MCP server. When I ask my AI client "what is stuck," it does not grep my tasks for a status flag. It pulls from three domains and joins them:
Tasks: what has an open state and no activity since a threshold date
CRM: when the linked customer was last contacted, and what that interaction said
Ledger: whether money tied to that work is outstanding
The answer comes back as a picture, not a list. Something like: this task has not moved in 11 days, the client on it went quiet after asking about scope, and their invoice from last month is still open.
None of those three facts is alarming alone. Together they mean the engagement is stalling and I need to send an email today.
That is the whole thesis of the project. A single question that reasons across CRM, financials, and memory beats three tools that each answer a fragment perfectly.
Why it is an MCP server and not an app
I did not want another dashboard. I have enough dashboards. I wanted the context to live inside the tool where I already think, which for me is Claude, and for other people is Cursor or something else entirely.
MCP makes that portable. Same server, any client. I move between tools during the week and the business context follows me instead of getting stranded in a tab.
Where the data sits
It runs over stdio against your own Postgres. You deploy it, you own the database, you point it at your own instance.
This was deliberate. I was not going to put my client list, my contact history, and my books into a hosted service I do not control just to make an AI assistant slightly more convenient. If someone else wants to run it against their own infra, the setup is the same for them as it is for me. No lock-in by design, because the design never assumed a middleman.
It is MIT licensed and it is what I actually use to run my business every day.
GitHub: https://github.com/OurThinkTank/founders-os
Site: https://foundersmcp.com
npm: @ourthinktank/founders-os
The question I keep chewing on
Everyone building AI tooling right now is solving retrieval. Fewer people are solving the join. Getting the right document into context is easy compared to getting the right relationship between three records in different systems into context.
If you are building in this space, I would like to hear how you handle it. The joins are where the real work is.
Top comments (1)
The join is the valuable part, but I would make it deterministic before asking the model to interpret it. Each result should carry the task ID, customer ID, invoice ID, join keys, source timestamps, and an explicit as-of time. Otherwise a stale CRM sync can look exactly like a quiet client. I would expose a bounded
find_stalled_engagementsview/tool that computes the cross-domain signals and returns the evidence envelope; the model can summarize and prioritize it. That keeps “stuck” explainable instead of turning a useful business rule into an opaque inference.