Most "AI in [product tool]" features ship the same shape: bolt a chat agent onto the database the tool already had, expose it over MCP, call it done. Productboard's agent reads Productboard. Linear's agent reads Linear. Notion's agent reads Notion.
That's a tool-MCP: an AI host can call one product's API. Useful — but it inherits that tool's biggest limitation. It only ever sees one slice.
Here's the query that breaks it:
"Which paying customers are blocked on open feature requests?"
To answer, you need the feedback (support/insight tool), the accounts and their revenue (billing), and the open work (issue tracker). Three tools, three identity models, no shared key. A tool-MCP over any one of them can't answer it — not because the model is weak, but because the context is amputated.
Tool-MCP vs spine-MCP
- Tool-MCP — exposes one product's objects. The AI reasons over a slice.
- Spine-MCP — exposes a joined record. The AI reasons over the whole product: the feedback, the feature you shipped for it, the revenue it moved, and the commit that shipped it — on one row per customer.
The wedge isn't "more tools in a box." It's the join.
What it looks like
Point your own AI host at the spine — one line, OAuth, no API-key paste:
claude mcp add aioproductos --transport http https://aioproductos.com/api/mcp
```
{% endraw %}
Same idea, different config file for ChatGPT, Cursor, Codex, Windsurf, and Cline. OAuth 2.1 + DCR + PKCE.
Then ask, from the host:
> "Which paying customers are blocked on open features?"
{% raw %}
```text
SAML/SSO $13,000/mo · 4 accounts · open · in current sprint
Audit Log $3,690/mo · 2 accounts · shipped · 100% adoption
Usage Alerts $1,900/mo · 1 account · open
...
```
{% endraw %}
The answer comes from the data — the join — not from the model's guess.
## The part devs actually ask: is the "AI" real?
Honest answer: the retrieval is deterministic, the narration is the model. A question hits a classifier, a deterministic SQL reader pulls the joined rows, and the LLM narrates the result. The numbers aren't hallucinated because the model never computes them — it reads them.
(Gartner reckons 40%+ of "agentic AI" projects get cancelled by 2027, mostly because the "agent" was a chat box over a thin database. Over-prove, don't over-claim.)
Same substrate powers assignable AI teammates — Backend, Frontend, QA. They claim a task over MCP, do the work in your own coding host, and submit for human review before anything ships.
## When a tool-MCP is enough (the honest counter-case)
If your question lives entirely inside one tool — "what's in this sprint," "summarise this doc" — a tool-MCP is simpler and you don't need a spine. Spine-MCP only earns its keep when the answer spans tools: revenue × feedback × work × code. We don't out-feature Linear on sprint mechanics or Amplitude on analytics depth; the whole bet is the join *across* them.
## Try it
- **Read-only demo, no signup:** [aioproductos.com](https://aioproductos.com) → "Browse the live demo" (there's a skip link). Real seeded workspace, writes blocked.
- **MCP endpoint:** {% raw %}`https://aioproductos.com/api/mcp`
If you build MCP servers, I'd genuinely value the critique: where does "one record" break for your workflow?
Top comments (0)