Analytics dashboards answer the questions somebody anticipated when they designed the screen. The questions you actually have on a Tuesday afternoon are rarely on that list. “Did anything change on mobile in the last fortnight?” “Which of the two cold brew posts is pulling its weight?” “Is that traffic spike real or a bot?” Each of those is three or four clicks through filters, and by the time you’ve built the segment you’ve usually forgotten what you were looking for.
Must-Have Analytics 1.0.2 takes a different route: it publishes the whole reporting engine as tools an AI assistant can call. Point Claude at your site and you can ask the question in English, and it runs the same reports the dashboard runs — on your server, with your permissions, read-only.
This article covers what is actually exposed, how to connect it, what it is genuinely good for, and where it stops being useful. We set it up on a test install with a month of seeded traffic and drove it from a real Claude session; the transcripts below are that session’s output, not mock-ups.
What is being connected, exactly
Three pieces stack up here, and it helps to keep them separate.
- The Abilities API is WordPress core, from 6.9. It is a registry of typed, permission-checked capabilities: each one declares an input schema, an output schema and a permission callback. Must-Have Analytics registers 15 of them.
- MCP — the Model Context Protocol — is the open standard AI clients use to discover and call tools on a server. It is what lets an assistant find out that a “run analytics report” tool exists and what arguments it takes.
- The MCP Adapter plugin is the bridge: it takes registered abilities and serves them over MCP. Must-Have Analytics uses it to register its own named server, so an assistant sees one tidy “Must-Have Analytics” server rather than a generic pile of WordPress tools.
The endpoint is /wp-json/mhanalytics/mcp. Without the MCP Adapter the abilities still exist and are usable from WP-CLI, the REST API or any code calling wp_get_ability() — they are simply not reachable over MCP. On WordPress older than 6.9 the whole integration switches itself off silently.
The 15 tools
They fall into four groups:
- The full engine.
run-reportruns any report from the dashboard — pageviews, bounce rate, country, landing and exit pages, devices, traffic sources, sessions, goals, speed, UTM, search statistics, bot traffic — with the complete segmentation filter set, custom date ranges and daily/weekly/monthly/yearly granularity. With WooCommerce active it also covers purchase trends, top products, view-to-purchase, abandoned carts, refunds, failed orders, coupon usage and customer lifetime value. - Sessions. Paginated session lists, the full journey of a single session (pages, time on page, scroll depth, events, goals) and a live view of who is on the site right now.
- Filter discovery.
list-pages,list-traffic-sources,list-goalsandlist-productsexist so the assistant can turn “the cold brew post” into the ID that the report filters actually want. - Quick summaries. Visitors overview, top pages, traffic sources, top countries, device breakdown, landing pages and latest goals — for when a full report would be overkill.
Every one of them is read-only and annotated as such in the protocol. Nothing in this surface writes to your database, changes a setting, or publishes anything.
Connecting it
You need four things: WordPress 6.9 or newer, Must-Have Analytics 1.0.3 or newer, the MCP Adapter plugin (from the WordPress organisation on GitHub — it is not in the plugin directory), and an application password.
1. Create the credential
Users → Profile → Application Passwords. Give it a name you will recognise later and copy the generated password — WordPress shows it once.
Two things are worth doing properly here. The account needs the mhanalytics_report capability — administrators have it by default, and if you would rather not hand an AI client an administrator credential, create a dedicated user with only that capability. And MCP inherits that user’s permissions exactly: the assistant can read what that user could read in wp-admin, and nothing more.
2. Point the client at the endpoint
The endpoint is https://yoursite.com/wp-json/mhanalytics/mcp, authenticated with HTTP Basic using the WordPress username and the application password.
In Claude Code, add it as an HTTP server:
claude mcp add --transport http roastworks-analytics \
https://yoursite.com/wp-json/mhanalytics/mcp \
--header "Authorization: Basic $(printf 'user:app password' | base64)"Then run claude mcp list. A healthy connection reports the server as connected; if you added it as a project-scoped server you will be asked to approve it the first time you start an interactive session.
Clients that only speak the local stdio transport — Claude Desktop among them at the time of writing — need a small proxy in between. The documentation points at @automattic/mcp-wordpress-remote for this, configured with your site URL, username and application password; the adapter also ships a STDIO transport through WP-CLI for local development. The MCP client landscape is moving quickly, so check what your client supports natively before adding a proxy you may not need.
What it is actually good for
Everything below ran against a test install: WordPress 7.1, Must-Have Analytics 1.0.3, MCP Adapter 0.6.1, and a seeded dataset of about a month of traffic for a small coffee shop — 1,841 sessions, 4,712 pageviews, 50 orders. The dataset is synthetic; the questions, the tool calls and the answers are not.
Use 1: the question you would not have clicked for
The obvious use is the boring one, and it is still the one you will reach for most: a plain-language summary that would otherwise be four screens and a mental note.
The last paragraph is the interesting part. Nobody asked “which topic is doing the acquisition work” — it added up the two blog posts, compared them to the homepage and said so. That is the difference between a dashboard and something that can hold several numbers at once.
Use 2: diagnosis, not description
This is where it stops being a nicer way to read a chart. We seeded a deliberate problem into the dataset — a mobile-only LCP regression starting mid-month — and asked a vague question of the kind a shop owner would actually ask, without naming the metric, the date or the device.
It found the step change and dated it to 11 August. It established the regression was mobile-only and sitewide rather than page-specific. Then it did the thing that makes this worth writing about: it noticed that TTFB and FCP were unchanged while only LCP moved, ruled out the server on that basis, and concluded the largest element was arriving late — an image delivery or lazy-loading change. It also flagged a pre-existing layout shift problem on the busiest product page that had nothing to do with the question.
That is a chain of five or six reports and a comparison across two date windows. It is entirely doable by hand. Almost nobody does it by hand.
Equally worth noting: asked whether the slowdown was hurting conversions, it said it could not verify that, explained why (no goals configured in the test dataset), and pointed out that bounce rate had not moved — mild evidence against the simple story. An assistant that tells you which half of your question it could not answer is considerably more useful than one that fills the gap.
Use 3: the reports nobody opens
Most sites use perhaps four of the twenty-odd reports Must-Have Analytics ships. The rest — exit pages, search statistics, bot traffic, view-to-purchase, abandoned cart, coupon usage, customer lifetime value — are perfectly good reports that stay closed because nobody remembers they exist. An assistant with the full list in front of it will use them when the question calls for it, without you knowing which report to ask for.
Where it stops
Four honest limits, in the order they will matter to you.
- Your data leaves your server when you ask. This is the one to think hardest about. The analytics themselves stay in your database and no third-party script runs on your visitors’ browsers — that part of the privacy story is unchanged. But the moment you ask an assistant a question, the tool results travel to whoever runs the model. Session-level tools can return IP addresses and individual journeys. If that is a problem for your compliance posture, the
mhanalytics_mcp_toolsfilter lets you withhold specific tools from MCP while keeping them in wp-admin; the documentation shows exactly this withget-session-details. - It reads; it does not act. Nothing here changes a setting, fixes a page or sends a report. It answers questions.
- Numbers still need a sanity check. The figures come from the same engine as the dashboard, so they are as right as your dashboard is — but the interpretation is the model’s. In our own test run the assistant twice flagged that a number looked too good to be an honest signal. Treat the analysis as a well-briefed colleague’s first pass, not a finding.
- It costs tokens. A broad question can run six or eight reports and pull a lot of rows. That is fine occasionally and adds up if you wire it into something that runs hourly.
Who should bother
Worth setting up if you already live in an AI assistant during the working day, if you manage several sites and the per-site dashboard tour is the reason you skip it, or if the questions you have about your traffic are diagnostic (“why did this change”) rather than descriptive (“what is the number”).
Skip it if you look at two numbers a week and the dashboard already shows both, if your compliance position rules out sending visitor-level data to a model provider, or if you are on WordPress older than 6.9 and not planning to move.
Frequently asked questions
Can the AI change anything on my site through this?
No. Every ability in this integration is read-only, declares itself as read-only and non-destructive in the protocol, and is permission-checked against the mhanalytics_report capability. Note that this covers the Must-Have Analytics server specifically — other plugins can register their own abilities, and those may not be read-only.
Does this work with ChatGPT, or only Claude?
MCP is an open standard, so any MCP-capable client can connect. We tested with Claude. What differs between clients is the transport they support — some speak remote HTTP directly, others need a local proxy — and how they handle authentication headers.
Do I need the MCP Adapter plugin?
For MCP, yes. Without it the abilities are still registered and usable from WP-CLI, the REST API and PHP — you simply have no MCP server for a client to connect to.
Can I limit what the assistant can see?
Two ways, and they compose. Use a WordPress user with only the capability it needs, so the permission check does the work; and use the mhanalytics_mcp_tools filter to remove specific tools from the MCP server while keeping them available in wp-admin. Returning an empty array from that filter skips server registration entirely.
Is the assistant reading my raw database?
No. It calls named tools with typed arguments, and the plugin runs the same report code the dashboard runs. There is no SQL access and no way to ask for a table it was not given a tool for.
The takeaway
The interesting thing about this integration is not that you can ask your site how many visitors it had. It is that the assistant can chain reports you would not have thought to open, hold the results side by side, and notice which metric didn’t move. In our test that turned a vague worry into a dated, device-specific finding with a plausible cause and a list of next checks — from a question that named neither the metric nor the date.
The setup is genuinely small: a plugin, an application password, one line of client config. The thing to decide before you do it is not technical but editorial — which of your visitor data you are willing to send to a model provider in exchange for answers. The tooling gives you the switches to draw that line; it will not draw it for you.
The full ability list, the filters and the extension points are in the AI Agents & MCP section of the documentation. If you want the background on the reports themselves, we have written about how the reporting compares to GA4, about server-side conversion tracking, and about a practical setup for privacy-conscious teams. For the standard itself, the Model Context Protocol site is the primary source.
