Why we built our own MCP server instead of an app marketplace
A marketplace makes every integration someone else's roadmap. A protocol makes it nobody's.
The obvious move for a delivery platform in 2026 is an app directory: publish an API, invite partners, curate a gallery. We started down that path and stopped, because every entry in that gallery is a promise that somebody will keep maintaining it.
MCP inverts the problem. Instead of building an integration per assistant, you expose one tool surface and any compliant host can use it.
One surface, thirty-one tools
The server exposes eighteen read tools and thirteen write tools. Reads cover the questions people actually ask — project status, delivery confidence, the blocker radar, why something is late, where the hours went. Writes cover creating and updating work, sprints, milestones, notes and time.
Claude, ChatGPT, Cursor, VS Code and anything else that speaks the protocol get the same surface. We did not write four integrations; we wrote one server.
The hard part was authorisation, not tools
A connection acts as the person who authorised it and can never see or do more than they can. That sounds obvious and it constrains everything: the tools cannot have their own service identity, they cannot cache across users, and every call has to resolve permissions the same way the UI does.
Write access is opt-in and executes immediately — there is no confirmation step between an assistant deciding to change something and it being changed. We say this loudly rather than burying it, because the safe default only works if people know why it is the default.
What we would not expose
Vault credentials are unreachable over MCP regardless of the connection's scope, and that restriction cannot be configured away. There is a category of data where the right answer is that the assistant simply does not get it, and stored secrets belong to that category.