Originally published at nlqdb.com/blog
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.)
Top comments (1)
The read/own split is useful but there's a case it doesn't quite cover. I run a travel connector - the agent looks up car rentals, airport transfers, eSIM plans, and then deliberately hands the user off to the provider's page to actually book. Read-only on purpose, not because I ran out of time: if I took the payment I'd own refunds, liability and PCI scope for a service somebody else operates.
On "they look identical in a comparison table" - that's getting less true at the client level, at least in Claude. My tools get sorted into Read-only and Interactive groups automatically, off the annotations the server declares, and each group has its own permission toggle. So users see which kind they're dealing with before anything gets called.