Every data tool shipped an MCP server this year. Your agent still can't build on most of them.

MCP is the new "we have an API." Writing a competitor comparison recently, I went to mark "agent-callable" as our differentiator against an AI data-notebook tool — and stopped, because they'd shipped an MCP server too. So had the BI tool two rows up. The honest move was to concede the checkbox. But conceding it surfaced the real axis, and it's one worth naming.

Two shapes of MCP server

There are two shapes of MCP server, and they look identical in a feature matrix. The first wraps a destination app: "ask my published notebook a question," "answer from my dashboard in Slack." The human's workflow, now reachable by an agent. The second exposes infrastructure the agent owns: provision a database, write rows, query them, migrate the schema. Both speak MCP. Only the second lets an agent build something that outlives the conversation.

The tell is to ask what the agent owns after the call returns. If the answer is "a view into a human's analysis," that's a genuinely useful human-in-the-loop surface — and a dead end for an autonomous agent, because the agent can read but can't accumulate. It has nowhere to put the row it just computed. An agent that can query but not persist is a calculator, not a coworker.

"Does it have MCP" is the wrong question

So the question to ask a tool's MCP server isn't "does it exist" — by 2026 it always does. It's "what does it let the agent own?" Read-only over someone else's app, or a substrate the agent can write to and come back to. The matrix can't tell them apart; you have to read what the verbs actually do.

(At nlqdb the MCP verb nlqdb_query materialises a Postgres on first reference — omit the database id with none provisioned and it creates one from the goal, so the agent gets a database it owns, not a window into ours. The comparison that prompted this is at nlqdb vs Hex.)