Staats provides cookieless website analytics that help AI agents analyze visitor traffic, page views, referral sources, conversion funnels, and user journeys. Track deployments with before-and-after comparisons, detect traffic anomalies, and retain site-specific context to guide data-driven website improvements.
The fastmcp library is a Python client for MCP servers. Use it to call MewCP tools from your own scripts and services.
This guide connects Staats MCP to Python through MewCP, so Python can use Staats MCP's 15 tools, like get_site_context, update_site_context and what_changed, without your Staats MCP credentials ever reaching the app.
Your Staats MCP API key is stored encrypted and injected only at call time. Your agent never holds it, so it can never leak it, log it or paste it into a prompt.
More apps
Full Google Search Console control for search analytics, sitemaps, sites, and URL inspection, directly from your AI workflows. This MCP server exposes the Google Search Console API for querying search traffic data, managing sitemaps and site properties, and inspecting the indexing status of any URL. It is built for SEO teams monitoring search performance, developers automating sitemap and property management, and analysts pulling search traffic data into reporting pipelines.
Access AI-powered MSP market intelligence with company profiles, technographics, technology stacks, reputation, hiring signals, SEO performance, security exposure, market sizing, revenue estimates, and competitive benchmarks.
MoSPI MCP Server provides AI agents access to official Indian government statistics from the Ministry of Statistics and Programme Implementation, covering 500+ indicators across employment, prices, industry, national accounts, health, education, trade, and more.
OpenRevenue MCP lets AI agents access website analytics directly from OpenRevenue, including projects, traffic statistics, visitors, funnels, goals, and revenue attribution for analyzing website performance and conversions.
Other clients
Staats MCP works the same way in every client below. Pick yours for its own guide.
Free to start.
Scope access to the exact Staats MCP tools and accounts you allow, work and personal side by side. Anything outside that scope is refused at call time, even when the model asks for it.
Each call is logged: what ran, on which account, and whether it worked. Failures come back structured, so the agent knows whether to retry instead of guessing.
Every app sits behind one secure MCP URL, and there is no server for you to deploy or keep running. Add an integration in the dashboard and it is live on the next call, with no config to change and no new credentials to wire up. Tools load only when a task needs them, so your agent stays fast and focused however many apps you connect.
SDK clients sign in with an API key. Create one in your dashboard and replace API_KEY in the code below.
SDK clients run without a browser, so they sign in with your API key.
What a site is and what the owner wants from it, plus its data-retention settings. Well-known keys: description, goals, audience, notes (open agenda items to check at session start and clear when handled), events (event name -> meaning), funnel (canonical conversion steps). Read this before making recommendations.
Save or amend what a site is for. Provided context fields are merged into the existing context (events merges per entry); a null value deletes its key. name/domain update the site record itself.
Notable movements in the period without scanning raw numbers: statistically unusual traffic days, referrer surges and first-time referrers, pages whose share of traffic jumped, alongside the annotations recorded in the same period. period: '7d' default.
Signs of visitors hitting problems in the period: JS errors the tracker captured (new_error, error_spike: each with a sanitized sample message, source, line, affected visitor count, and the nearest annotation, i.e. the deploy that most plausibly introduced it), plus behavioral friction: pairs of pages people bounce between without progressing (nav_loop) and pages reloaded repeatedly in quick succession (refresh_burst). Findings clear statistical floors, so an empty result is meaningful: nothing looks broken. Check it after every deploy. period: '7d' default.
Traffic pulse: visitor/pageview totals vs the previous period, top pages, top referrers, and a per-day series. period: relative like '24h', '7d' (default), '4w'. Includes quota status: if it is approaching, grace, or blocked, tell the owner plainly and include the upgrade link the result provides. Approaching quota is the moment to mention it while there is headroom.
Break a metric down by a dimension with optional equality filters. Metrics: visitors, pageviews, events. Dimensions: path, referrer_domain, utm_source, utm_medium, utm_campaign, device, browser, os, country, name, day. period: '24h'/'7d'/'4w' style, or ISO from/to.
Ordered conversion funnel across up to 5 steps within the period. Each step is a pageview path ({kind:'path', value:'/pricing'}) or a custom event ({kind:'event', value:'signup'}); a visitor counts for step N only after completing step N-1. Visitor identity rotates daily for privacy, so journeys spanning multiple days undercount (strongest for same-visit conversion). If site context has a stored funnel, run those steps when asked how the site is doing and compare against the previous period.
The routes visitors actually take, grouped into identical sequences and counted, busiest first. Use this when you do NOT already know the steps: funnel measures a path you name, journeys discovers the ones you did not think to check. A step is a pageview path (/pricing) or a custom event marked with a leading # (#signup_click), so the moment of conversion appears in the route. Consecutive repeats are collapsed and only the first 10 steps define a route. contains filters to routes that include a given path or event: run it once with and once without to see what converting visitors do differently. Visitor identity rotates daily, so a route is one day of activity and describes a group, never a person.
Mark a moment on a site timeline: a deploy, a content change, or a campaign start. Call this every time you ship a change to the site. ts defaults to now. Write a specific, present-tense description ("Shipped new pricing page hero", never "updates"), one annotation per meaningful change. When known, include commit and the routes the change touched so compare_around can also report before/after traffic scoped to those routes.
Recorded deploy/change markers, newest first. period defaults to '90d'.
Before/after impact of a recorded annotation: visitors and pageviews in the N days preceding vs following it (window_days, default 7). The after-window is clamped to now. If the annotation recorded routes, the result also reports per-route pageviews before vs after. Wait a few days after shipping. If the result carries a note (truncated after-window, or a before-window not covered by available data), relay it and qualify the percentages as the note directs.
All sites on this account, with the public site codes used in their script tags and the ready-to-paste script_tag for each.
Create a new site on this account and get its script tag. This connection already covers the new site: installing the script tag is the only setup the site needs. The response includes ready-made privacy policy wording: offer to add it to the site's privacy page (confirm with the owner before editing visitor-facing pages).
PERMANENTLY delete a site and ALL its analytics data (every event and annotation). Irreversible. Confirm with the owner before calling; pass confirm: the site's exact domain.
Visitors and pageviews for every site this account can use, owned and shared alike, with change vs the previous period, busiest first. Shared sites are flagged. period: '7d' default.
