TL;DR: The new datavessel MCP server release lets you talk to every connected source — GA4, Search Console, Shopify, Shopware, WooCommerce, HubSpot, WordPress — from a single chat in Claude Desktop, Cursor, or any MCP-aware client. AEO tools (citation tracking across ChatGPT, Claude, Gemini, Perplexity) now live behind the same server, available to every BYOK user. Every action is classified as read or write, and writes require explicit approval. Plus the usual reliability fixes.
We’ve shipped a new version of the datavessel MCP server. Two things changed that are worth paying attention to. First, you can now address every one of your connected sources from a single chat surface — you don’t have to think about which connector you’re talking to. Second, every tool the server exposes is now labelled as read or write, and write actions don’t run until you say yes.
One Chat, All Your Sources
The original use case for the datavessel MCP server was narrow: someone in Claude Desktop wanted to ask Claude a question about their Shopify store, so they wired up the Shopify connector and asked. That worked, but it left a gap. The moment the question crossed two sources — “which blog post drove the most Shopify sales last month?” — the user had to think about which tools were available, which were enabled in this client, and whether the answer they were getting was actually using both connections.
The new release closes that. One MCP endpoint exposes every source you’ve connected in datavessel. GA4, Search Console, Shopify, the new Shopware connector, WooCommerce, HubSpot, WordPress — they all live behind the same server, and the agent picks the right tool for the question. You don’t enumerate connectors per query. You just ask, and the cross-source questions work the same way they do in the web chat.
This matters because the interesting analytics questions almost always need at least two sources. Traffic plus revenue. Search rankings plus conversion. Email campaign plus store orders. Anything one connector can answer alone, your existing tools could already answer. The work was always in the join — and joins now happen by default.
Including the AEO Tools, for Every BYOK User
The other change in this release is which tools the MCP server exposes. Until now, the server was the analytics surface — read your traffic, query your store, pull your search rankings. The AEO product, where you track LLM citations across ChatGPT, Claude, Gemini, and Perplexity, was its own thing with its own interface.
That separation is gone. The new MCP server exposes the AEO tools alongside the analytics ones. From the same chat where you ask “is my traffic up this week?” you can now ask “and which queries did Perplexity actually cite us for?” — and the agent calls the citation-tracking tools the same way it calls GA4. One server, two product surfaces, no extra setup.
Every tool is available to every user who connects their own AI account. If you’re on the main analytics platform with your own Claude, ChatGPT, or Gemini key, you get the AEO tools too. There’s no tier where the AEO product is gated behind a separate subscription at the MCP layer — the model you brought is the model that calls every tool. That’s the byo-key promise applied consistently.
Read vs. Write — and Why the Distinction Matters
Every tool the MCP server exposes is now classified explicitly as either a read or a write action. Reads are anything that pulls data: list orders, fetch a Search Console query, pull a GA4 report. Writes are anything that changes state in a connected system: publish a WordPress draft, create a HubSpot contact, push a Shopware landing page.
Reads run immediately. Writes do not.
When a write action is about to fire, datavessel pauses and asks for explicit approval. In the web chat, that’s a button — the agent shows you exactly what it’s about to do, against which source, and waits. In MCP clients like Claude Desktop, the approval comes through the standard MCP confirmation prompt that already exists in those tools. Either way, no write ever happens without you seeing it first and clicking yes.
This is a deliberate choice. The fashionable thing in agent products right now is to let the model do everything autonomously, then promise that it’s “smart enough” to be trusted with your data. We don’t believe that. Models are wrong often enough — and writes are expensive enough to undo — that the right default is to pause and confirm. The cost of an unnecessary confirmation click is a second. The cost of an unintended write to a production CMS or a customer database is the rest of your afternoon.
What Counts as Destructive
“Destructive” in our model is broader than “deletes data.” Anything that creates, updates, or removes a resource in a connected system requires approval — publishing a draft is destructive in the sense that the published page is now public, even if nothing was deleted. The user can’t be expected to mentally model the difference between an update and a delete in every connector. They can be expected to read what the agent is about to do and click yes.
The list of destructive actions includes: publishing or updating WordPress posts, creating or modifying HubSpot contacts and deals, writing Shopware landing pages, posting Slack messages on your behalf, scheduling agents, and changing any datavessel configuration that affects other users in the workspace. The full list lives in each connector’s documentation, but the rule is simple: if it changes something in a system other than datavessel’s own read cache, it’s a write.
Why This Is the Platform Working
The original pitch for datavessel was that you could talk to your data in plain English. That pitch held up when the data lived in one source. The harder, more interesting version of the same idea is when the data lives in five sources and the question crosses three of them. The new MCP release is what that version looks like in practice — and the read/write distinction is what makes it safe to use the same chat for both questions and actions.
“Show me which blog posts converted the most Shopify sales last month, then draft a refreshed landing page for the top one and publish it as a WordPress draft” is one sentence. It touches GA4, Shopify, and WordPress. The reads run, the agent assembles the answer, the draft gets written, and the publish step pauses for your approval before going live. None of that requires switching tools, copying between tabs, or trusting the agent with unsupervised write access.
Reliability Fixes
The same release includes a round of reliability work — connection error handling, retry behaviour on rate limits, cleaner error messages when a connector is in a bad state. Nothing user-facing in the changelog-headline sense, but the practical effect is that the MCP server stays up under more conditions than it did last week.
How to Get It
If you’re already using the datavessel MCP server in Claude Desktop, Cursor, or another client, the new version rolls out automatically — your client will pick it up on the next refresh. If you’re using the web chat, the multi-source behaviour and approval flows are live now, no action needed.
If you haven’t wired up the MCP server yet, our Shopify-to-Claude setup guide walks through the same connection flow that now exposes every other source you’ve added.
Sources
- What Is MCP? — Background on Model Context Protocol and why it’s the foundation of this release.
- 12 Plain-English Questions for Shopify Owners — Concrete examples of what the multi-source chat is good at.
- Design Sweep and Shopware Connector — The Shopware connector that now joins every other source behind the new MCP endpoint.
Leave a Reply