DEV Community: Quentin Wendegass

Quite interesting how many different bots come to your site.

Quentin Wendegass — Tue, 03 Nov 2026 10:41:51 +0000

Quentin Wendegass

Nov 3

ClaudeBot, GPTBot, ChatGPT-User: which AI crawler does what

#ai #webdev #seo #agents

11 min read

ClaudeBot, GPTBot, ChatGPT-User: which AI crawler does what

Quentin Wendegass — Tue, 03 Nov 2026 10:40:14 +0000

Open your server log and you find names like ClaudeBot, GPTBot, ChatGPT-User, OAI-SearchBot and meta-externalagent. They are AI crawlers, and they are not all doing the same thing. Most AI companies send up to three of them, each for a different job.

One collects pages to train future models. One keeps the company's search index up to date. And one reads a single page right now, because a person just asked ChatGPT or Claude a question that page answers. Which one you are looking at decides what blocking it does, whether it listens to your robots.txt, and whether your analytics will ever see it. Below is what each company documents, and what actually came to our own site in five days.

Every AI company's crawlers by job, as each company documents them. Checked 3 November 2026.

Three jobs, three crawlers

Collecting training data. GPTBot, ClaudeBot, meta-externalagent and their kind copy public pages into the data future models learn from. They crawl on their company's schedule, not because anyone asked anything. Blocking them keeps your pages out of future training sets. It does not remove anything already collected, and it does not stop the same company from finding and quoting your pages.

Reading for its search. OAI-SearchBot, Claude-SearchBot and PerplexityBot build the search index the AI service answers from, much like Googlebot does for Google. A page that is not in that index cannot turn up when someone asks. Blocking a search crawler is how you disappear from that service's answers, which is usually not what a site owner wants.

Reading for an answer. ChatGPT-User, Claude-User and Perplexity-User request one page at the moment a person needs it: someone pasted your link, or the service decided your page answers their question. Each request is one person's question. This is the closest thing to a visit an AI service makes, and it is the one your analytics never shows (more on that below).

Each job is its own name in robots.txt. OpenAI and Perplexity say plainly that every setting is independent, and Anthropic describes what blocking each of its three crawlers does on its own. Blocking GPTBot keeps ChatGPT's search and answers exactly as they were.

Every AI crawler, by company

What each company documents about its crawlers, in its own words where it matters. Each company's page is linked; that is where to look when a name changes.

OpenAI: GPTBot, OAI-SearchBot and ChatGPT-User

GPTBot collects training data: disallowing it "indicates a site's content should not be used in training generative AI foundation models." OAI-SearchBot builds ChatGPT's search, and "sites that are opted out of OAI-SearchBot will not be shown in ChatGPT search answers." ChatGPT-User reads a page when someone asks ChatGPT or a custom GPT something, and "because these actions are initiated by a user, robots.txt rules may not apply." OpenAI adds that if you allow both GPTBot and OAI-SearchBot, it may use one crawl for both purposes. Changes to robots.txt take about 24 hours to reach its search. OpenAI's crawler page

Anthropic: ClaudeBot, Claude-SearchBot and Claude-User

ClaudeBot collects training data. Blocking it "signals that the site's future materials should be excluded from our AI model training datasets." It also honours Crawl-delay, if you want it to come less often. Claude-SearchBot builds Claude's search, and Claude-User reads a page when someone asks Claude a question. Anthropic says all three follow robots.txt, and that blocking Claude-User "prevents our system from retrieving your content in response to a user query." That makes it the only company of the big ones whose answer crawler listens to robots.txt, and our own test agrees: Claude asked for robots.txt one second before it read the page. ClaudeBot is also quick: on our test site it arrived within minutes of the TLS certificate being issued, before anyone had the link. Anthropic's crawler page

Google: Googlebot, Google-Extended and the Gemini crawlers

Google has no separate AI training crawler. Google-Extended is "a standalone product token": a name you use in robots.txt to say whether pages Googlebot already crawled may train Gemini and ground its answers. No request ever carries it, and it "does not impact a site's inclusion in Google Search." Google's page does not mention AI Overviews; they come from the ordinary search index, which Googlebot builds. For reading on a person's behalf, Google lists Google-Agent (agents that "browse and act on user request") and Google-GeminiNotebook (pages someone added as sources), among other user-triggered fetchers that "generally ignore robots.txt rules." The Gemini app itself is not on that list: in our test it read the page as a bare Google. Google's common crawlers, user-triggered fetchers

Perplexity: PerplexityBot and Perplexity-User

PerplexityBot builds Perplexity's search and "is not used to crawl content for AI foundation models"; Perplexity documents no training crawler. Perplexity-User reads a page for a person's question and "generally ignores robots.txt rules." In our test, though, Perplexity answered a person's question with PerplexityBot, so you can see the search crawler's name on a request that was really for an answer. Perplexity's crawler page

Meta: meta-externalagent, meta-webindexer and meta-externalfetcher

meta-externalagent crawls to "train foundation AI models or to improve products by indexing content directly". meta-webindexer improves search results in Meta AI, and allowing it "helps us cite and link to your content." meta-externalfetcher reads individual links at a user's request, and "may bypass robots.txt rules." As with Perplexity, our test saw Meta AI answer a question with meta-webindexer. The link previews in Facebook, Instagram and WhatsApp come from a fourth name, facebookexternalhit. Meta's crawler page

Mistral, Amazon, Apple and Microsoft

Mistral has the clearest names: MistralAI-Training, MistralAI-Index and MistralAI-User. It doesn't say whether MistralAI-User follows robots.txt; in our test it read robots.txt once and then every page twice in the same second. Mistral's page

Amazon sends Amazonbot, which "may be used to train Amazon AI models", Amzn-SearchBot for search, and Amzn-User for questions such as Alexa's, which "may not follow all robots.txt directives." Amazonbot does more than training, so blocking it costs more than a training opt-out. Amazon's page

Apple crawls with Applebot for Siri, Spotlight and Safari. Applebot-Extended is a robots.txt name like Google-Extended: it "does not crawl webpages", and disallowing it keeps your pages out of Apple's model training while they stay in search. Apple's page

Microsoft documents no separate AI crawler. Copilot answers from Bing's index, which bingbot builds, so blocking bingbot removes you from Bing and Copilot at once.

The ones that don't say

Some AI services document nothing we could check. Bytespider is ByteDance's crawler; reports disagree on whether it respects robots.txt. xAI documents no crawler for Grok, and in our test Grok's browsing agent looked exactly like a person's Chrome, from the person's own connection. DeepSeek read our page in a full browser with an ordinary Firefox user agent. Nothing in a log line names either of them.

What actually came to our site in five days

From 29 October to 2 November 2026 our server reported every crawler request to privatrak.com and its subdomains: 3,785 requests. 1,661 of them, 44%, carried the name of an AI crawler.

Requests per crawler name on privatrak.com, 29 October to 2 November 2026, as our server reported them.

Training came first. GPTBot requested 384 pages in five days, more than any other crawler, search engines included: Bingbot requested 297 and Googlebot 133.

Answers were the smaller part, and the most valuable. ChatGPT-User requested 62 pages and Claude-User 27, each one a person whose question our page answered. 46 of ChatGPT's were for the home page.

At least 635 of the 1,661 AI-named requests, 38%, were not AI crawlers at all. They asked for .env files, /proc/self/environ, private keys and docker-compose.yml: files no website shows its visitors, which scanners try in the hope of finding a leaked password. Under the names of answer crawlers there were more of these (146) than page requests (97). Perplexity-User asked for a secret file 36 times out of 40, DuckAssistBot 38 out of 42, Claude-SearchBot 47 out of 52. Nobody borrowed Meta's names, the one large company whose crawlers can't be checked against a published IP list.

llms.txt was hardly read. Across every crawler, it was requested three times in five days: once each by GPTBot, Googlebot and GoogleOther. ClaudeBot, on the other hand, asked for robots.txt 30 times while requesting 19 pages.

One site, five days. The 38% is a lower bound: it counts only requests for files that are never a page, so a scanner asking for /admin under ChatGPT's name counts as a page request.

What robots.txt can and can't do

robots.txt is a request, not a lock. The training and search crawlers of the companies above say they follow it. The crawlers that read for an answer mostly say they may not, on the grounds that a person asked: OpenAI, Google, Perplexity, Meta and Amazon all say so in one form or another. Anthropic is the exception.

So the choice robots.txt gives you is mostly about training. If you want to stay out of training sets but keep turning up in AI answers, block the training names and leave the rest alone:

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: meta-externalagent
User-agent: MistralAI-Training
User-agent: Amazonbot
User-agent: CCBot
Disallow: /

CCBot is Common Crawl, whose public archive many models are trained on. Amazonbot is there because Amazon says it may train on what it collects, but it also feeds other Amazon products, so leave it out if that matters to you. Expect a day before a change takes effect: OpenAI and Perplexity name about 24 hours, Meta caches robots.txt for up to 24 hours and Amazon for up to 30 days.

Why your analytics shows none of this

Analytics tools such as Google Analytics, Plausible or Privatrak count a visit when the page's JavaScript runs in a browser. A crawler that reads the page as text never runs it. When we sent AI services to a test site, ChatGPT, Claude, Gemini, Perplexity, Mistral and Meta AI all read the page without running a single script. None of them reached our analytics, Google Analytics included.

Our own site agrees. In the five days above, ChatGPT-User, Claude-User and the other answer crawlers requested 97 pages and left not one page view in our analytics. Search crawlers sometimes do run the script: OAI-SearchBot showed up 4 times and meta-webindexer 10 times.

That is fine for training and search crawlers, which you don't want in your visitor numbers anyway. It is a real gap for the answer crawlers. Each of their requests is a person asking an AI service a question your page answers, and that is a number worth knowing. It shows whether AI services read you at all, which pages they read, and whether that turns into visitors clicking through.

Only your server sees those requests. Your server log has them; so does a log at your CDN. Privatrak can count them if your server reports the requests it answers: a setting in the WordPress plugin, a Cloudflare Worker, or a few lines in Next.js or Nuxt. Your server only reports requests from known crawlers, so nothing about your visitors leaves it. The AI services page then shows how often ChatGPT, Claude and the others read your pages for an answer, next to the visitors they sent you.

Is it really ClaudeBot? Check the IP address

A user agent is a claim, and anyone can make it. Google says as much: user agent strings "can be spoofed." On our own site, at least 38% of the requests carrying an AI crawler's name were scanners (see above), borrowing a name that sites tend to let through.

The one reliable check is the address the request came from. Most companies publish the IP ranges their crawlers use, and a request from outside them is not that crawler, whatever it says it is:

Company	Crawlers	IP lists
OpenAI	GPTBot, OAI-SearchBot, ChatGPT-User	gptbot.json, searchbot.json, chatgpt-user.json
Anthropic	ClaudeBot, Claude-SearchBot, Claude-User	bots.json
Google	Googlebot, Google-Agent, Google-GeminiNotebook	googlebot.json, user-triggered-fetchers-google.json, user-triggered-agents.json
Perplexity	PerplexityBot, Perplexity-User	perplexitybot.json, perplexity-user.json
Mistral	MistralAI-Index, MistralAI-User	mistralai-index-ips.json, mistralai-user-ips.json
Amazon	Amazonbot, Amzn-SearchBot, Amzn-User	Amazonbot, Amzn-SearchBot, Amzn-User
Apple	Applebot	applebot.json
Microsoft	bingbot	bingbot.json
Meta	meta-externalagent, meta-webindexer, meta-externalfetcher	none published

Every list was reachable on 3 November 2026. Mistral publishes none for MistralAI-Training. Google and Microsoft also document a reverse DNS check, and Bing has a Verify Bingbot tool.

Meta is the one large company that publishes no list, so a request calling itself meta-externalagent can't be checked this way. The lists also change, so a firewall rule built from them needs refreshing. Anthropic warns that blocking by IP "may not work correctly or persistently guarantee an opt-out": the lists are for checking who a request is from, robots.txt is for saying what you want.

The short version

One AI company, up to three crawlers: one for training, one for its search, one that reads for a person's answer. Each is a separate name in robots.txt.
Blocking a training crawler keeps you out of future training data and nothing else. Blocking a search crawler takes you out of that service's answers.
Crawlers that read for an answer mostly don't follow robots.txt. Anthropic's does.
None of the AI services we tested ran the page's JavaScript, so only your server sees them.
On our site, at least 38% of the requests under AI crawler names were scanners looking for passwords, and llms.txt was requested three times in five days.
A name is a claim. The published IP lists are how you check it.

Originally published on the Privatrak blog. Privatrak is privacy-first product analytics that counts how often ChatGPT, Claude and Perplexity read your pages for an answer, apart from training and search crawlers. Try the live demo.

Over the last days I did a lot of research and testing on how to detect AI agents on your website. Long story short: It's not so easy.

Quentin Wendegass — Tue, 27 Oct 2026 08:07:06 +0000

Quentin Wendegass

Oct 27

We sent 23 AI agents to our website. Most looked human

#ai #webdev #agents #analytics

15 min read

We sent 23 AI agents to our website. Most looked human

Quentin Wendegass — Tue, 27 Oct 2026 07:57:21 +0000

AI assistants now open websites for people. You ask ChatGPT to compare two pricing pages, and a browser somewhere clicks through them for you. We build an analytics tool, so we wanted to know what that looks like from the other side: does a visit like this show up as a person, as a bot, or not at all?

So we built a small test site, gave two dozen AI agents, chatbots and developer tools the same task, and recorded every request they sent and every click they made. Then we did the same task ourselves, with a trackpad, a mouse, phones and two accessibility tools, to see where people and agents differ.

The short version: most agents that use a browser look exactly like a person in Chrome. They report no automation, send a normal Chrome user agent, and many came from our own home connection. Only a few said what they were, and only one, Manus, signed its requests so a site can check it. Most chatbots that just fetch a page name themselves to your server and never reach your analytics, but two of them run your scripts and show up as a visitor who leaves at once. How long an agent holds the button didn't give them away: two of them wait like a person. How the pointer gets to the button did, for every clicking agent we tested.

Tested on 26 October 2026: 49 runs by 23 AI agents, chatbots and tools and 8 human setups, with every request and every click recorded. Every visitor got the same task on the same three pages. The method and its limits are at the end.

The test

The test site was a made-up notes app with three pages: a home page, a plans page and a contact page with a form. The plans page has the detail we asked about, whether the Team plan includes single sign-on, in a comparison table that starts collapsed. Every agent got the same prompt:

Go to [the address] and find out what the Team plan costs per month and whether it includes SSO. Then open the contact page and tell me what it asks for. Don't submit anything.

Each run had its own address, so every request in the server log belongs to one known visitor. A small script on the page reported what the browser said about itself and how each click happened. It never read what anyone typed.

We tested:

AI agents that use a browser: ChatGPT Work's built-in browser in the ChatGPT desktop app, Claude in Chrome, Claude Cowork, Claude computer use, Grok's desktop app, Perplexity's Comet browser and Manus.
Tools developers give their agents: Vercel's agent-browser, Playwright MCP and Chrome DevTools MCP (driven by Claude Code), the open-source Browser Use, a plain Playwright script, and the same script in a Browserbase cloud browser.
Chatbots that fetch the page: ChatGPT, Claude, Gemini, Perplexity, Mistral Le Chat, Meta AI, DeepSeek, Claude Code, Jina Reader and Browserbase's hosted agent.
People: a Mac trackpad, a mouse, Windows, two iPhones, an Android phone, and the macOS accessibility tools Voice Control and Dwell, which click for you.

Some we couldn't test. Gemini in Chrome told us it can't control the browser here, and its browsing agent is reportedly limited to paid plans in the US. We didn't run OpenAI's computer-use model. Microsoft Copilot in Edge seemed to answer from the page we had open, without a request of its own, so there was nothing to record.

The results at a glance

	Browser	Says it's automated	Came from
ChatGPT Work	Chrome 156 on our Mac	No	Our connection
Claude in Chrome	Our own Chrome	No	Our connection
Comet, in our browser	Comet (Chrome 145) on our Mac	No	Our connection
Comet, in the cloud	Windows Chrome	No	A data centre
Grok	Linux Chrome without a graphics card	No	Our connection
Claude computer use	Chrome on a Linux desktop	No	Where it runs
Claude Cowork	Headless Chrome in the cloud	Yes	Anthropic's servers
Manus	Linux Chrome in the cloud	Yes, and signs its requests	A data centre
Browser Use, Playwright MCP	Chrome on our Mac	No	Our connection
agent-browser, DevTools MCP, Playwright script	Chrome on our Mac	Yes (`webdriver`)	Our connection
Same script in Browserbase	Linux Chrome	No	A data centre
ChatGPT, Claude, Gemini, Perplexity, Mistral, Meta AI	None	In the user agent	Their servers
Jina Reader, DeepSeek	Chrome, Firefox	No	A data centre

Every agent that finished the task gave the answer our test page was built to give: €9 a month, no SSO, and the four fields of the contact form.

Most agents look like a person in Chrome

Bot detection usually starts with three questions: does the browser say it's automated (navigator.webdriver), does the user agent name a bot, and does the visit come from a data centre. For most agents the answer was no to all three.

ChatGPT Work ran a Chrome 156 inside the ChatGPT desktop app on our Mac. It reported webdriver: false, a normal Chrome user agent, our timezone, our graphics chip and our home IP address. The only odd things were a narrow window, 319 pixels wide, and speed: a full visit took 11 to 21 seconds. Google Analytics showed these visits as ordinary sessions. So did our own tool. In 2025, Simon Willison found that ChatGPT's agent signed its requests so sites could verify them. In our runs, ChatGPT Work's browser sent no signature at all.

Claude in Chrome runs in your own browser, so it is your browser: same version, same extensions, same IP address. There's nothing to tell apart. Comet, when it worked in our Comet window, was the same: a Chrome 145 user agent with no mention of Comet or Perplexity, from our connection.

Grok was the strangest. The requests came from our IP address with our timezone, but the browser reported Linux on an x86 processor, 8 cores and no graphics card, on an Apple Silicon Mac. So it wasn't our browser, but to the website it came from our connection. We don't know where that browser runs. Its user agent was plain Linux Chrome, and nothing named Grok.

Claude computer use sees the screen through screenshots and clicks through the operating system, the way a person's mouse does. We ran it like Anthropic's reference setup, in a Linux desktop in Docker. It also reported a plain Linux Chrome with webdriver: false.

Among the developer tools, Browser Use and Playwright MCP look like plain Chrome too. A plain Playwright script reports webdriver: true; Playwright MCP switches that off. A Browserbase cloud browser hides it as well, but comes from a data centre, so an IP check would catch it.

A few say what they are. Claude Cowork's browser announced itself as HeadlessChrome/153 with webdriver: true, from Anthropic's servers and a different IP address for almost every page. Vercel's agent-browser and Chrome DevTools MCP report webdriver: true as well. And Manus went furthest: it adds Manus-User/1.0 to its user agent and signs every page request with a Signature-Agent: "https://api.manus.im" header and a cryptographic signature (the Web Bot Auth standard, an IETF draft), so a site can check that the request really came from Manus. It was the only agent in the test that did.

One agent, two browsers

We gave Comet the same prompt six times. Three times it worked in our own Comet window. The other three times it used a browser in Perplexity's cloud: Windows, a server graphics card, a Los Angeles timezone and an Amazon data-centre address. When we started two tasks at once, the first ran in our browser and the second in the cloud.

Asked why, Comet told us it uses the cloud browser for public pages and our own browser only when a site needs our login. That isn't what it did: it used our browser three times for the same public page. The two browsers also click differently, as the next sections show. So the same product can reach your site as a person on a home connection or as a server in a data centre.

Many came from our own connection

ChatGPT Work, Claude in Chrome, Comet in our browser and Grok all reached the site from our home IP address, with our timezone, and so did every developer tool we ran on our Mac. That's worth knowing if you filter bots by IP address or by "data centre or not": for these agents, a website sees the same address as the person who sent them.

Agents that only read

Asked the same question, Grok answered everything correctly, and even worked out the monthly price itself (€10.80), without a single click, scroll or mouse movement. It typed the addresses of the plans and contact pages directly and read the SSO answer out of the table that was still collapsed on screen. Manus did the same: three pages typed in 21 seconds, no click, no scroll, no movement.

In analytics that's three page views, almost no time on each page, and no interaction: it looks like a visitor who left straight away. In fact it's a visitor who read everything. When we told Grok to click around, it did, and then it clicked like the other agents below.

Most chatbots that fetch the page name themselves

When you paste a link into a chatbot and ask for a summary, most don't open a browser. They fetch the page once from their own servers. No script runs, so an analytics tool that counts with a script in the page never sees the visit. Your server does, and most of these are easy to tell apart: they say who they are in the user agent, and most vendors document it (OpenAI, Anthropic, Perplexity, Google, Mistral, Meta).

	User agent	Checked robots.txt first
ChatGPT	`ChatGPT-User/1.0`	No. OpenAI's search crawler fetched it 33 seconds later
Claude	`Claude-User/1.0`	Yes, one second before
Gemini	`Google`	No
Mistral	`MistralAI-User/1.0`, every page twice in the same second	Yes, the first time
Meta AI	`meta-webindexer/1.1`, the name of Meta's indexing crawler	Yes, as `facebookexternalhit`
Claude Code	`Claude-User (claude-code/…)`, asks for Markdown first	No

Perplexity (PerplexityBot/1.0) fetched robots.txt and then our start page instead of the address we gave it, twice. The start page of the test site is empty, so it told us it couldn't fetch the page. Another time it said the page "returned no readable content" without sending us a single request.

Browserbase's hosted agent, asked to do the full task, didn't use a browser either. It fetched the pages with headers that imitate Chrome 146 on macOS, ten versions behind everything else in the test, and requested two pages in the same millisecond from two different IP addresses.

Two "fetchers" run your scripts

Two of the chatbot tools didn't just fetch the page. They opened it in a real browser, so our script ran, and an analytics tool would count a visitor.

Jina Reader, a service agents use to turn a page into text, loaded it in a headless Chrome in a data centre. Its user agent said plain Linux Chrome 156; only a second version header, which said 155, showed that the user agent had been changed.

DeepSeek opened the page in Firefox 149 on Linux, with Chinese as its language and a Hong Kong timezone, from a Huawei Cloud address in Hong Kong, and was gone within three seconds. Nothing it sent named DeepSeek or a bot.

In analytics, both are a visitor who loaded one page, did nothing and left.

What gave the clicking agents away

Once an agent clicks, we could compare its clicks with ours. The first thing we measured, how long the button is held, worked for most agents and failed for two:

	Button held	Last pointer move before the click
Most agents	0 to 13 ms	1 to 63 ms before
Browser Use	82 to 90 ms	134 to 142 ms before
Comet in our browser	265 to 453 ms	531 to 755 ms before
People with a mouse or trackpad	29 to 266 ms	21 ms to 2 seconds before

Browser Use and Comet in our browser press, wait and release like a person. Comet in the cloud didn't: it held the button for 10 to 13 ms.

What gave every clicking agent away was how the pointer got to the button. A person moves a hand, so the pointer arrives in many small steps; the last step before a click was 0 to 2 pixels for every one of our clicks. An agent doesn't move a hand. Before each click, the pointer appeared on the target in a single jump of 200 to 840 pixels, or it appeared there for the first time on the page, and it barely moved otherwise:

	Agents	People with a mouse or trackpad
The last move before a click	One jump onto the target	A small step, 0 to 2 pixels
Other pointer movement on the page	0 to 2 movements	11 to 642

This held for all 13 kinds of clicking agent, in every run: those that click through Chrome's remote-control interface, Claude computer use, which clicks through the operating system, and the two that wait like a person.

Signals that didn't hold up

Some things that sound like good bot signals failed on our own data:

How long the button is held. Most agents click in a few milliseconds, but Browser Use and Comet hold the button as long as people do, and the accessibility tools below click faster than any agent.
Clicking dead in the centre of a button. ChatGPT Work did, usually within a pixel. But Claude in Chrome and Claude computer use aim at the text they see in a screenshot, and missed the centre of a wide element by more than 230 pixels. And one of us hit a link within 2 pixels of its centre with a trackpad.
A big jump of the pointer. A fast swipe on a trackpad moved the pointer 701 pixels in one step. Only a jump that lands right on what is clicked next is suspicious.
Pressure. ChatGPT Work and Comet reported a pressure of 0 when they clicked, where a mouse reports 0.5. The Playwright tools reported 0.5.
How it navigates. ChatGPT Work typed the addresses in some runs and clicked the links like a person in others, with the same browser.
The console trick for spotting remote control. Tools that drive Chrome through its remote-control interface often listen to the browser console. Bot-detection scripts exploit that: the page logs an error object that notices when something reads it, and a listening tool does. It noticed nothing in any browser we tested, Playwright included, so it doesn't work in the Chrome versions we saw (136 to 156).

Accessibility tools look more like bots than the bots

macOS Voice Control lets you click by saying what to click. Every one of its clicks landed exactly in the centre, with the button "held" for less than a millisecond, a pressure of 0, and no mouse movement at all. On any single signal, it looked more automated than ChatGPT Work.

Dwell clicks for you when you rest the pointer on something. Its clicks were also held for 0 to 3 milliseconds.

Both differ from the agents in how the pointer moves: Voice Control never moves it before clicking, and with Dwell the pointer rests on the target for about three seconds, moved there by a hand in small steps. A detection rule that relies on click timing would label people who can't use a mouse as bots. The movement tells them apart, but that's the only thing that does.

What this means for your analytics

AI agents are already in your numbers as people. Short visits that read everything and click nothing, and visits that go straight to pricing, may be agents.
Most chatbot fetches are counted on the server. They never reach a script in the page. To see how often someone asks ChatGPT, Claude or Mistral about your pages, count ChatGPT-User, Claude-User and MistralAI-User requests on your server. Some, like DeepSeek's, show up in analytics as a one-page visit instead.
Don't count on IP addresses. Most of the agents we ran came from our home connection.
Be careful with "bot" filters. If a filter catches instant, centred clicks, it also catches people using Voice Control.

What we're changing in Privatrak

Privatrak already marks visits as automated when the browser says so (webdriver) or the user agent names a headless browser or an agent like Manus. In this test that caught the Playwright script, agent-browser, DevTools MCP, Claude Cowork and Manus. ChatGPT Work, Claude in Chrome, Comet, Grok, computer use, Browser Use, Playwright MCP and the Browserbase browser were counted as people.

We're adding a check in the browser for the movement pattern above: a visit is only marked when every mouse click on the page came after one jump of the pointer onto the target, with almost no other movement, so Voice Control and Dwell users stay people. Replayed on our recordings, that marks every clicking agent and none of us. The browser only sends "automated" or not, never the movements themselves. A marked visit is still counted, and you decide whether to leave automated visits out of your numbers. Agents that only read, and fetchers that run your scripts, will still look like people.

For chatbots that only fetch, we're working on counting them from your server: a small addition for your site sends only the requests whose user agent names a known chatbot or crawler, and Privatrak shows which pages ChatGPT, Claude and Perplexity fetched for someone, separate from your visitors.

Also seen

Visitors before anyone had the link. Within minutes of the site's certificate being issued, scanners that watch the public certificate logs visited it, some claiming to be Chrome. Anthropic's crawler ClaudeBot came by twice the same morning.
Link previews. When people opened the test links we'd sent them, WhatsApp and Facebook's preview fetchers got there first.
Google came back on its own. Right after an agent's visit fired the Google Analytics tag, a Google fetcher (GoogleOther) loaded the same page.

Every user agent we saw

For reference, here is the user agent each one sent, copied from our server log. Only the rows marked "Yes" ran the page's scripts, so only those can reach an analytics tool that counts with a script. The agents that drive a browser, ChatGPT's agent included, send an ordinary Chrome user agent; only Claude Cowork, agent-browser and Manus give themselves away in it.

	User agent	Runs your scripts
ChatGPT Work (ChatGPT's agent)	`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/156.0.0.0 Safari/537.36`	Yes
Claude in Chrome (your own browser)	`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/155.0.0.0 Safari/537.36`	Yes
Comet, in your browser	`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36`	Yes
Comet, in Perplexity's cloud	`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/156.0.0.0 Safari/537.36`	Yes
Grok	`Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/156.0.0.0 Safari/537.36`	Yes
Claude computer use	`Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/156.0.0.0 Safari/537.36`	Yes
Claude Cowork	`Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/153.0.8010.12 Safari/537.36`	Yes
Manus	`Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/156.0.0.0 Safari/537.36; Manus-User/1.0`	Yes
Browser Use	`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36`	Yes
Playwright MCP, DevTools MCP	`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/156.0.0.0 Safari/537.36`	Yes
Vercel agent-browser	`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/156.0.0.0 Safari/537.36`	Yes
Jina Reader	`Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/156.0.0.0 Safari/537.36`	Yes
DeepSeek	`Mozilla/5.0 (X11; Linux x86_64; rv:149.0) Gecko/20100101 Firefox/149.0`	Yes
ChatGPT, reading a link	`Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot`	No
Claude, reading a link	`Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Claude-User/1.0; +claude-user@anthropic.com)`	No
Claude Code	`Claude-User (claude-code/2.1.309; +https://support.anthropic.com/)`	No
Gemini	`Google`	No
Perplexity	`Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)`	No
Mistral Le Chat	`Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; MistralAI-User/1.0; +https://docs.mistral.ai/robots)`	No
Meta AI	`meta-webindexer/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)`	No

How we tested

The test site ran on our own server, with three static pages. The server log recorded every request with all its headers. A script on each page reported what the browser said about itself (user agent, webdriver, window size, timezone, graphics) and how each click happened: how long the button was held, how the pointer moved before it, and how many movements there were in total. It never read what was typed into the form.

Each agent ran in its own way:

ChatGPT Work, Grok, Cowork, Comet, Manus and the chatbots were run by hand in their own apps or websites, on free plans where possible.
Claude in Chrome ran in our own Chrome.
Claude computer use ran on Claude Opus 5.5 with the computer-use toolset, in a Linux desktop in Docker that clicks with xdotool, like Anthropic's reference setup.
agent-browser, Playwright MCP and DevTools MCP were driven by Claude Code on our Mac; Browser Use ran on our Mac with Claude Sonnet 4.6 and its default settings.
The Playwright script ran in Chrome on our Mac and in a Browserbase cloud browser. Jina Reader was called without an account.

Limits to keep in mind:

It's one day and one site: one to six runs per agent, and ten runs by people, most of them by us.
Agents change quickly. A new version can click differently tomorrow.
An agent that moves the pointer along a path in small steps would look like a person. None of the agents we tested did.
Where Grok's browser runs, and what makes Comet choose a browser, is what we observed, not something we could confirm.

What it took to get our MCP server into Claude's connector directory

Quentin Wendegass — Thu, 22 Oct 2026 09:52:18 +0000

An automated review approved Privatrak for Anthropic's connector directory about an hour after we submitted it. Here's what the submission involved, what tripped us up, and what we'd do again.

Our MCP server is now listed in Claude's connector directory. An automated review approved it in about an hour. We build Privatrak, a cookieless analytics tool, and MCP (Model Context Protocol) is the standard way to plug a tool like it into an AI assistant. Once connected, Claude can answer your analytics questions in plain language or set up the tracking for you, such as funnels, dashboards and which clicks count as which feature.

This is what getting it into the directory actually involved, in the order we ran into it. Most of it applies to any remote MCP server, not just analytics.

An AI reviewed it, not a person

The approval email said the submission "was reviewed and approved as a community connector by an automated review of the listing." Anthropic's verification page explains what that means. Every submission is scanned automatically for policy compliance and listed as a Community connector by default. Listings that look highly useful to Claude users can be escalated to Verified review, which is slower and where "reviewers run a functional test of each tool." That escalation is decided automatically too, and there's nothing to apply for.

The label changes less than you might think. Once connected, a Community connector works exactly like a Verified one, it shows up in search, and Claude can suggest it in a chat when it fits. The difference is the label, and a reminder before someone connects that it "hasn't been reviewed in depth." You can't apply for Verified. Anthropic picks listings that look "highly useful to Claude users", and its developer portal ranks every listing by how many people use it. So our bet is that usage is what counts.

That changes how you write the submission. The first thing to read your tool descriptions is an automated check against Anthropic's policy, and the strictest rules there are about text that steers Claude into doing something the user didn't ask for (more on this below). The test account and test plan the form asks for may be looked at too, but the only review that says it runs every tool is the Verified one. So they have to work without you there to explain them.

A few months ago this looked very different. Submissions went through a Google Form and a manual queue, and developers reported waiting months without hearing back. Anthropic has since moved submissions to a portal with an automated check, and some submissions still get a review by a person, with times that depend on the queue. We don't know why ours went through in an hour. Our guess is that a clean submission, with OAuth, honest tool labels and a full test plan, gives the automated check nothing to send on to a person.

Why we needed OAuth sign-in

Claude on the web, the desktop app and the mobile apps connect to a remote server by URL. For most users there is nowhere to paste an API key (at the time of writing, a beta that accepts one is rolling out to some customers), so a server that only accepts keys locks most people out. And the directory requires OAuth anyway.

So we built sign-in with OAuth, the same flow as any "Sign in with..." button. Claude sends you to our login page, you approve access, and Claude gets a token for our server. Here's what we learned from making it work with the apps people actually use.

Claude introduces itself with a web address. Claude doesn't register with your server in advance. Its ID is a URL that points to a small file describing Claude (a Client ID Metadata Document). You fetch that file and check that the address you send people back to after sign-in is listed in it. Cursor and Codex instead register themselves on the fly (dynamic client registration), so you need both if you want to support them too.
Claude Code picks a random port. After sign-in, it expects to be sent back to http://localhost/callback, on whatever port it happened to open. The OAuth rules for desktop apps (RFC 8252) say to ignore the port for localhost addresses, and you have to, or Claude Code's sign-in fails.
Don't trust the name an app gives itself. An app that registers on the fly can call itself "Claude". Our approval screen only shows a name as checked when the file describing the app and the address it returns to are on the same domain, such as claude.ai. Otherwise it shows the domain next to the name and marks it as not checked.
The approval screen is where people decide. Ours asks which projects the connection may see, and whether it may only read or also make changes. Those two choices match the two kinds of API key we already had, so an AI connection can never do more than a key could.

On the submission form, all of this was one line. Behind that line was the biggest piece of work.

The checkbox that made us stop

Every tool comes with a short description that tells Claude what it does and when to use it. Claude reads these descriptions almost like part of its instructions, which is why the directory checks them closely. The last step of the form has seven boxes to tick. Six were simple. This one wasn't.

Tool descriptions contain no instructions about model behavior, other tools, or external instruction sources, and no hidden or encoded text.

Read literally, ours break it twice. First, some tool descriptions mention other tools, such as "use the ID you got from start_setup_run". Second, the general instructions our server gives Claude tell it how to behave, such as "quote counts with every percentage", so that it says "2 of 4 visitors" instead of just "50%". We wanted to keep both, because they make the tools work better.

So we read the policy the checkbox summarises. Its actual rules are narrower.

Descriptions must say precisely what a tool does and when to use it, and match what it does.
A server must not push Claude toward calling other software the user didn't ask for, or interfere with other servers' tools.
It must not tell Claude to fetch behavioural instructions from external sources.
No hidden, obfuscated or encoded instructions. In the policy's words, "all behavioral guidance must be human-readable and clearly presented."

Anthropic's pre-submission checklist is more blunt. "Describe what the tool does, and don't tell Claude how to behave." But the most useful part is the last rejection reason on its list, descriptions that "tell Claude to behave in ways unrelated to the tool's function."

So guidance about what your own tools do is allowed. What isn't allowed is guidance that pulls Claude away from what the user asked, toward someone else's tools, or that is hidden. Referring to your own tools, telling the model how to read your own numbers, and pointing it at your own documentation as reference material are all fine, as long as it's in plain sight.

We ticked the box and explained it in the notes field instead of hoping nobody would notice. We listed which tools our descriptions refer to, why the usage guidance is there, and that our two documentation tools only read our own public documentation, from a fixed list of pages.

The automated review approved it, so that reading seems to hold. If you're building a server, write descriptions as if a reviewer will read every one, because one will, and the first one is automated. Name only your own tools, keep all guidance visible, and if a sentence would read as manipulation out of context, rewrite it.

When Claude asks before using a tool

The directory requires three labels on every tool, a title and two hints called readOnlyHint and destructiveHint. They decide when Claude asks for permission. According to the checklist, read-only tools "can run without per-call confirmation, and destructive tools always prompt." Get them wrong and people either have to confirm every harmless lookup, or aren't asked before something is deleted.

Why does the directory check them so closely? The MCP specification says clients must treat these hints as untrusted unless they come from a trusted server, and yet Claude uses them to decide when to ask. Our guess is that the review is what earns a server that trust.

Watch out for one thing. ** if you leave destructiveHint unset on a write tool, the protocol assumes it is destructive. ** That is a safe default, but it describes a "create dashboard" tool wrongly. So we set both hints explicitly on every write tool.

Creating something is not destructive, and running it twice gives you two of them.
Updating, renaming, deleting and undoing are destructive, and running them twice does no more than running them once.
Some tools need a closer look. In Privatrak, a click problem is something people click that doesn't work. Marking one as fixed is destructive, and doing it twice is not the same as once, because it moves the date from which the problem counts as happening again. Marking it as ignored twice really changes nothing the second time.

Setting up a test account

Test credentials are required, and the checklist says they "must be for a fully populated account." For analytics that matters more than for most tools, because an empty project answers every question with zero.

This part was easy for us, because we already run a public demo with a sample shop and its traffic. We created a dedicated account on the Pro plan, with a project holding a month of the same kind of shop traffic, with visitors from search and campaigns, product pages, a checkout funnel, user journeys and a few broken buttons for the click-problem tools. One detail almost tripped us up. Our funnels only count from the day they were created, so a funnel added on the day of submission would have shown nothing. Everything in the review project had to look as if it had been there for the whole month.

Give the account a plain email and password. One team was rejected because their review account used Google sign-in with a code sent to a phone, which the reviewer couldn't get past. Their server was fine.

Writing a test plan

The form asks how to test the server. Our first draft was a handful of example prompts, and they were useless. Five nice prompts exercise maybe a dozen tools. They show the server works, not that every tool does.

So we wrote a plan of 15 prompts that together call all 44 tools, each with the tools it triggers and the answer we got, so the reviewer can check rather than guess. Here's step 4.

4. "Which properties can I filter by, and which page paths exist? Then chart
   page views and clicks per day from 2026-10-13 to 2026-10-19 and compare
   them with the week before."
   Tools: list_property_keys, list_property_values, run_insights_query.
   Expect: 162 page views (+25.6%), 53 clicks (+23.3%).

Fixed dates matter here. "Last week" means something different every day the reviewer opens the plan.

The harder part is the write tools. A reviewer has to create, change and delete things to test them, on an account other reviewers may use after them. If the plan leaves a mess, the second run fails.

This is where a design decision from months earlier paid off. In Privatrak, every change an assistant makes belongs to a setup run, and a setup run can be undone in one step. Undo puts back exactly what the run changed. If someone has changed the same thing since, it skips that item and says so instead of overwriting their work. The undo tool first shows what it would do, and only then does it.

So the last step of the plan cleans up after everything else.

15. "List the setup runs and show what 'Review test' changed. Then undo it:
    dry run first, then for real."
    Tools: list_setup_runs, get_setup_run, undo_setup_run.
    Expect: 15 changes listed; the undo reverts all 15 with nothing skipped.
    The project is back to its original state.

We ran the whole plan ourselves through Claude, signed in as the review account, before submitting. The form's Test & launch step asks you to confirm you tested every tool, and this was how we could say yes. Every tool passed, and the undo left the project exactly as it was. The plan can be run as often as anyone likes.

We don't know whether the automated review looked at it. We'd write it again anyway. It's what a Verified reviewer would follow, and it was the only way we knew that all 44 tools work through Claude itself, not just in our own tests.

We built setup runs for customers, not for reviewers. Letting an AI change your analytics setup is only reasonable if you can take it all back. But if your server has write tools and no way to undo them, think about how a reviewer is supposed to test them. And then about how your users are supposed to trust them. We wrote up how our undo works in a separate article.

Small things that cost us an afternoon

Claude Code took 25 seconds to connect. The cause was one default setting. The Go SDK we use tells every client that our list of tools may change while it's connected (listChanged: true). Claude Code waited for an update that never came, then gave up after about 25 seconds. Our tool list never changes, so we turned the setting off (listChanged: false) and Claude Code now connects right away.
** Claude's desktop app won't send your API key in the usual place. ** You can add your own connector there with extra request headers, but not the Authorization header, where API keys normally go. So we also accept the key in an X-API-Key header, which our API already used. People who prefer a key over signing in can still connect.

What about the official MCP Registry?

One thing confused us at the start. Besides Anthropic's directory there is the official MCP Registry (registry.modelcontextprotocol.io), a public list of MCP servers run by the people behind the protocol. The two are separate. The registry wants proof that you own the name you publish under, and Anthropic's form never mentions the registry at all.

We did both. To publish as com.privatrak/analytics in the registry, we had to prove we control privatrak.com. You do that by adding a DNS record with a public key to your domain, then signing in with the matching private key using the registry's mcp-publisher tool. The one snag was that the tool needs the private key as hex, and the command in the instructions to get it didn't work with our version of OpenSSL. This one works with any version.

openssl pkey -in key.pem -outform DER | tail -c 32 | xxd -p -c 64

The registry entry itself is a small server.json with a name, a title, a one-line description, your website, an icon and your server's address. Write the description for someone deciding whether to install you, not for search engines. Ours says "Ask your website analytics in plain language and set up funnels, features and dashboards."

A checklist for your submission

Anthropic's pre-submission checklist open next to the form. It spells out what the policy only implies.
Sign-in with OAuth that works for Claude (Client ID Metadata Documents) and for Cursor and Codex (dynamic registration), and ignores the port on localhost addresses.
The current MCP transport, Streamable HTTP. If your tool list never changes, set listChanged: false.
A title, readOnlyHint and destructiveHint on every tool, set deliberately.
Tool descriptions that refer only to your own tools, with all guidance in plain sight. Explain anything borderline in the notes.
A test account with realistic data, and dates in the test plan that don't move.
A test plan that calls every tool, with expected answers, and cleans up after itself.
Optionally, an entry in the official MCP Registry, via a DNS record on your domain.
A public privacy policy, linked in the submission.
A review account with a plain email and password, no Google sign-in or phone codes.
Patience with later changes. A new description or new screenshots are reviewed by a person, and that can take weeks while your listing stays live.

If you want to see what this looks like from the user's side, Privatrak is in the directory now as a Community connector, and our docs show how to connect it.

We gave our MCP server an undo button

Quentin Wendegass — Wed, 21 Oct 2026 03:56:08 +0000

Letting an AI agent change your product's settings is only reasonable if you can take it all back. So every change our MCP server makes goes into a run that can be undone in one step. This is how it works, and the decisions that turned out to be hard.

In July 2025, Replit's AI agent deleted a company's production database during a code freeze, then told the user the data couldn't be recovered. It could. Replit had a rollback, and the user restored everything from a checkpoint. The agent just didn't know the feature existed. Two lessons from that story shaped what we built: the agent has to know that undo exists, and people have to be able to undo without asking the agent.

We build Privatrak, a cookieless analytics tool. Its MCP server lets Claude, Cursor or Codex do more than read your analytics. They can set them up: feature rules that name what people click, funnels, dashboards, and marking click problems as fixed. 17 of its 44 tools change something.

Most MCP servers with write access rely on the client asking before each call. We wanted one more thing: after an agent has made twenty changes, you see all of them in one list and undo them in one step, without losing what you or a colleague changed in between.

Asking first isn't enough

Claude asks before it runs a tool marked destructive. That's good, and we set our tool annotations carefully for it. But it depends on the server labelling its tools honestly, which is why the MCP specification tells clients to treat those labels as untrusted unless the server is trusted. And it protects one call at a time, while an agent's work isn't one call.

Setting up a project takes a dozen or twenty writes: rules, a funnel built on those rules, a dashboard whose widgets query them. Nobody reads the fifteenth confirmation as carefully as the first. Security people call this confirmation fatigue, and OWASP's list of risks for AI agents includes it. And the mistakes in a setup rarely show in a single call. They show later, when a dashboard counts the wrong thing.

What you need then isn't another confirmation. You need to see everything the agent did as one unit, and to take that unit back. Developers have that for code in version control. Product settings usually have nothing like it.

Undo has to live in the server

Coding agents already have undo. Claude Code and Cursor keep checkpoints you can go back to. But both only cover files the agent edited. Claude Code's docs say changes made through commands aren't tracked, and Cursor's say restoring a checkpoint doesn't undo a database migration the agent ran. Once an agent calls an API, the client can't take it back. Only the service behind the API can.

MCP doesn't help here either. The specification asks clients to keep a person in the loop and to confirm tool calls, but it has nothing for transactions or rollback. So if you want undo for what an agent does in your product, you build it into your MCP server. That's what the rest of this article is about.

One task, one run

The unit of undo is a setup run. An agent starts one at the beginning of a task with start_setup_run and a label such as "Checkout tracking", then passes its id on every write. The run answers the question "what did the assistant do?"

Two rules make it reliable:

Nothing happens outside a run. A write tool called without a run id starts a run itself and returns its id. Even an agent that ignores the instructions leaves a trail that can be undone.
Runs that changed nothing don't clutter the list. If the API rejects a write, the tool deletes the run it had just started for it.

In the API, a write joins a run through a header, X-Setup-Run-ID, not a body field. DELETE has no body, and all fourteen write operations should join the same way. A write without the header takes exactly the code path it always took, so adding runs changed nothing that already worked.

The runs also show up in the dashboard under Settings, as AI assistant changes. The person who connected the assistant doesn't need the assistant to undo what it did.

Record before and after, in the same transaction

Every write that belongs to a run is saved together with a record of what it changed: the state before and the state after. Both are saved in one database transaction, so either both happen or neither does. The run is locked meanwhile, so nobody can undo it halfway through a write.

The recorded state is the whole definition: a rule's name and conditions, a funnel's steps, a dashboard with its widgets. Everything undo needs to rebuild it. The database enforces the shape: a creation has no "before", a deletion has no "after".

One detail cost us more time than the rest. Undo later compares these records with what is in the database now. If the same thing can be saved in two ways that mean the same, the comparison fails, and every undo looks like a conflict. So every write saves its input in exactly one form.

Undo walks backwards

Undo replays the run's changes newest first, in one transaction:

Created becomes deleted.
Updated gets back the fields the run changed.
Deleted is recreated, with its original id.

Newest first matters. An agent that created a rule and then renamed it has to unwind the rename before the creation. And if the run created something and later deleted it itself, there is nothing to do for it at all.

The original id matters more than it sounds. Dashboards, funnels and links refer to things by id. A recreated rule even gets its original creation time back, because the order of rules decides which name the journey view shows for a click. Undo should leave the project reading exactly as before, not just something equivalent.

Afterwards the run is marked as undone and its report is stored. Asking again returns the same report, and a write that tries to join an undone run is refused.

The undo starts with the agent's last change and works back to its first. The funnel you renamed stays, and everything else goes.

Never overwrite someone else's work

This was the hardest decision. Between the agent's run and the undo, people keep working. Someone renames a widget the agent made, or fixes a rule's condition. Undo must not destroy that.

So every change is checked before it is reverted:

Undoing a creation requires the thing to still be exactly what the run created.
Undoing an update requires every field the run changed to still hold the run's value. Fields the run didn't touch may have changed since. They are none of its business.
A dashboard the run created that now holds someone else's widgets is not deleted.
Recreating something that would go over the plan's limits is skipped, not forced through.

When a check fails, that one change is skipped and reported with the reason, and the rest of the run is still undone. We considered stopping the whole undo instead. But then one widget someone renamed would keep an agent's entire setup in place. Skipping and reporting gives people the undo they asked for, minus exactly the things they have since made their own.

What counts as someone's work was a decision too. Moving or resizing a widget doesn't count. Someone who drags an agent's widget aside hasn't made it theirs, and deleting it destroys nothing they did.

The preview is the real undo, rolled back

You want to see an undo before it happens. The MCP tool undo_setup_run does a dry run unless told otherwise, and the server's instructions tell the agent to show you the result first. In the dashboard, the dialog says "This is what undoing will do. Nothing has been changed yet." before the button.

The preview isn't a separate prediction. It runs the actual undo, every check and every write, inside the transaction, and then rolls the transaction back. A prediction written as separate code drifts away from what undo really does, and then the preview is wrong exactly when it matters. One code path can't disagree with itself.

Say what can't come back

Some things can't be undone exactly, and pretending otherwise is worse than saying so.

In Privatrak, a funnel counts from the day it is created. The per-visitor data that could recount earlier days is deleted every night, for privacy. That has two consequences for undo:

Undoing a funnel the agent created also deletes the days it has counted since. The preview says how many.
A funnel the agent deleted comes back with its name and steps, but it counts again from the undo. Its old days are gone, and the report says so.

The rule we took from this: when undo can't be exact, the preview has to say what will be lost, before anyone confirms.

Undo is the last line, not the only one

Undo is what makes write access reasonable, but it sits behind other guards:

Tools go through our own API. Each tool sends an ordinary request to our existing API, with the same authentication, validation, plan limits and project scoping as any other client. There is no second path to the data, so there is no second set of rules to get wrong.
Write access is a fixed list. A read-only connection can reach a fixed list of API endpoints. Write access adds exactly the endpoints the write tools need, and nothing else. Tests fail if the tools and the lists disagree, in either direction.
People choose at sign-in. Which projects the connection may see, and whether it may only read or also make changes.
Every call names its project. The server keeps no "current project" that one chat could switch for another.
The hints are honest. Creating isn't destructive. Updating, deleting and undoing are, so Claude asks before them.

When we submitted Privatrak to Claude's connector directory, the undo made one more thing possible: a test plan that calls all 44 tools on a shared review account and ends by undoing everything it changed.

If you build this yourself

Pick the unit: one task, one run. Make every write join a run, even when the agent forgets to start one.
Record the whole state before and after, in the same transaction as the write, saved in one fixed form so you can compare it later.
Undo newest first, in one transaction, and recreate deleted things with their original ids.
Check every change for conflicts. Skip and report; never force, and never give up on the whole run.
Make the preview the real undo, rolled back.
Say what can't come back, before it is lost.
Put undo where people are: in the tool for the agent, and in your product's UI for everyone else.

Privatrak's MCP server works with Claude, Cursor and Codex. Our docs show how to connect it.

Our analytics counted US visitors twice every evening. The bug was the word "day"

Quentin Wendegass — Fri, 16 Oct 2026 15:36:28 +0000

A tester in the US told us the numbers looked wrong. The cause was a single assumption about what a day is, and we now suspect it hides in a lot more software than analytics.

We build Privatrak, a cookieless analytics tool. In September one of our testers, who lives in the US, told us something was off. His data looked weird. There were more visits every day than there should have been.

He was right. For visitors in the US we were counting some people twice, every day, around dinner time. The reason is obvious in hindsight and was invisible before: we had never decided what a "day" is.

How we count people without a cookie

A cookie is a label stuck on a browser. Every page view carries it, so counting unique visitors is easy.

We don't store anything on the visitor's device, so we compute an identifier on the server from things every request already contains:

visitor_id = HMAC(daily_key, IP address + browser + site)

The same person on the same device produces the same identifier on every page view, so we count them once. We never keep the raw IP address or browser string, only the hash.

The daily_key is what keeps this private. If it never changed, the identifier would be a stable fingerprint that follows someone for months, which is exactly what cookie rules exist to prevent. So the key changes once a day. After the change, yesterday's identifiers can't be matched to today's.

What we hadn't thought about: "once a day" means "at some clock time". We had picked midnight UTC without realising it was a choice.

Midnight UTC is not midnight

Midnight UTC arrives at very different times of day depending on where your visitors are:

Your visitors are in	Midnight UTC is, for them
Los Angeles	4–5 pm
New York	7–8 pm
São Paulo	9 pm
London	midnight–1 am
Berlin	1–2 am
Dubai	4 am
Mumbai	5:30 am
Singapore	8 am
Tokyo	9 am
Sydney	10–11 am

(The ranges are the two sides of daylight saving time.)

For a European audience that moment is the middle of the night, so almost nobody is browsing and almost nobody gets split. For a US audience it lands in the early evening. Someone reads your pricing page at 7:50 pm, goes to dinner and comes back at 8:10 pm. The key changed at 8:00 (in winter it is 7:00). Same person, new identifier, two visitors.

That is why a tester in the US saw more visits than expected, and why a tester in Europe would never have noticed. We can't give you a percentage, because it depends on how long your visitors stay, how many come back the same evening and when your traffic peaks. What we can say is what happened after the fix: the difference was big, and his funnels improved as well.

The funnels make sense once you see it. A funnel follows one visitor from step to step, so someone who looked at the pricing page at 7:50 pm and signed up at 8:10 pm was two visitors, and neither of them ever completed the funnel. Once the day was cut in the right place, his funnel numbers also matched what the insights in the dashboard showed.

Who this affects

Not everyone. It takes distance: if your visitors live close to the timezone where the day is cut, almost nobody is browsing when it turns over, and nobody gets split. It bites when visitors are far from that boundary. For a product like ours, where customers and visitors can be in every timezone, any single fixed boundary can land in somebody's evening, so one boundary for everyone can't be right.

A site whose visitors are mostly in one region can fix it by choosing that region's timezone. A site with a truly worldwide audience can't make it go away, because some part of the world is always in the evening when the day turns over. The best you can do is cut the day where your own traffic is lowest.

It wasn't only visitors

When we looked, the visitor key was only one of two places that used the UTC day. The other was every daily bucket in the reports. We had two separate pieces of code that each decided independently that a day starts at midnight UTC. They happened to agree with each other, so the mistake didn't show up as a disagreement anywhere.

For a New York project, the bar labelled "Tuesday" actually held Monday 8 pm to Tuesday 8 pm. So the problem wasn't just a few extra visitors. Every day in the report was shifted. A newsletter sent at 9 pm on Monday would have appeared to work on Tuesday.

The fix: decide once, in one place

We gave every project a timezone and made it decide both things: the moment the key changes and the edges of every daily bucket. Now there is only one value, so the two can't disagree.

It looked like a small change. It wasn't.

A counted day is frozen. We delete the raw rows of a day once we've counted it, for privacy. So when someone changes a project's timezone, we can't re-count old days on the new boundary; the rows that would answer it are gone. A timezone change applies from then on, and the first day after a change is longer or shorter than 24 hours.

Daylight saving makes days 23 or 25 hours long. An hourly chart has 25 buckets on the day the clocks go back and 23 when they go forward. We label each bucket with the UTC offset at that moment, so there's one bucket per real hour.

This is not only an analytics bug

Once we'd seen it, we started spotting the same bug elsewhere. Plenty of software never decides whose day it is or when things reset, and just uses whatever clock the server has. Places we'd look:

Daily quotas and rate limits that reset at midnight UTC, so users elsewhere get their fresh allowance at an odd hour.
Streaks and daily goals. A streak that breaks because the server's midnight arrived mid-evening is a classic.
"Today" in dashboards and reports, especially when you compare it with another system's day, such as your payment provider's.
Daily budgets and billing periods that pace or reset by an account's day.
Scheduled digests and cron jobs. "Every day at 9 am" in whose 9 am?
Anything that rotates an identifier on a schedule: session IDs, rate-limit buckets, A/B test bucket seeds. If it changes at a fixed time, it splits whoever is mid-action, exactly like ours did.
Daylight saving, for everything that assumes a day has 24 hours.

What we'd do differently

The first time DATE(timestamp) or "reset at midnight" shows up in code, ask whose midnight it is. We didn't, and we found out when a tester in another timezone noticed.