Tool-MCP vs spine-MCP: why an AI agent needs the join, not one API

Bogdan Ciric — Fri, 03 Jul 2026 16:35:25 +0000

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?

DEV Community: Bogdan Ciric

Tool-MCP vs spine-MCP: why an AI agent needs the join, not one API

Tool-MCP vs spine-MCP

What it looks like