Connect your site to Claude
What you need before you start
Nothing you do not already have. The list is short on purpose, and two of the three items are free.
| You need | Why |
|---|---|
A site you can edit the <head> of | the tracker is one script tag, and it has to load on every page |
| An askbowtie account and its token | the token is what tells the server which sites are yours |
| Claude, Claude Code, Cursor or any MCP client | MCP is an open standard, so the client is your choice |
You do not need a credit card, a plan decision, or a migration. The free tier covers the tracker, the dashboard and an un-metered MCP up to roughly 100,000 events a month across every site on the account.
Step 1: add the tracker so there is something to read
An MCP server with no data connected to it answers every question with a shrug, so this step comes first. Paste your line into the <head> of your site:
<script src="https://askbowtie.com/bowtie.js" data-token="your-claim-token" async></script>Three details matter and each one has bitten somebody. The data-token in that snippet is a placeholder: yours is unique to your site and is how askbowtie confirms the site is yours, so copy the real line from your dashboard. Use async rather than defer, because the tracker needs to be listening for errors that happen while the page is still parsing. And never version the URL, since the loader updates itself.
WordPress, Shopify, Tag Manager and the site builders all work, because all of them are just ways of getting that one line onto every page. If you have not signed up yet, Get started covers this step and the two below it.
Step 2: connect the server
Two ways in, and which one you want depends on the client. Claude desktop and web take one click and a sign-in; Claude Code and everything else take one command with a pasted token.
Claude desktop or claude.ai: Settings, then Connectors, then Add custom connector. Enter a name and https://askbowtie.com/mcp as the server URL, then Continue. That opens askbowtie's own sign-in and consent screen, where you pick which site(s) Claude can reach.
Claude Code, Cursor, or any client that sets a header instead:
claude mcp add --transport http askbowtie https://askbowtie.com/mcp \
--header "Authorization: Bearer YOUR_TOKEN" --scope user--scope user is the part people skip and then miss. Without it the connection belongs to the directory you happened to be standing in when you ran the command, so your agent knows about your site in one project and not in the next.
| Client | How it connects | Scope of the connection |
|---|---|---|
| Claude desktop and web | Settings → Connectors → Add custom connector → sign in, above | your askbowtie account, all clients you're signed into |
| Claude Code | the claude mcp add command above | per user, or per directory without --scope user |
| Cursor and other MCP clients | an HTTP MCP server entry with the same URL and header | whatever that client offers |
The setup docs carry the current Claude Code command and are kept up to date there, so this page does not drift: see the tracking reference.
The tool list is fetched once, when the client connects. If you connected before a tool existed, your agent cannot see it until you restart the connection. This surprises people roughly once each.
Step 3: link your Google sources
The tracker gives your agent what happens on your site. Two Google products give it what happens before the visit, and both are optional.
| Source | What it adds | What the link grants |
|---|---|---|
| Search Console | queries, impressions, clicks and position, joined to your pages | read only |
| Google Ads | spend, campaigns and paid performance joined to conversions | read and write, because Google offers no read-only scope |
Both are one-time links under Settings, then Connectors, with one consent screen each. The write access on the Ads side is Google's constraint rather than a design choice, so it is fenced: management is limited to a domain's owners and admins, every change previews before it applies, budget changes and campaign creation sit behind a separate switch, and any campaign created this way starts paused.
The worked example: one command, then a real chain
Two things happen after that command, and it is worth seeing both.
First, the handshake. The client runs initialize, the two sides agree on protocol version 2025-03-26, and the client calls tools/list exactly once. It comes back with 47 tools, each carrying a description and an input schema. From then on your agent is choosing from that list without asking you which tool to use.
Then, the work. Here is a real sequence against askbowtie.com, read out of the per-call activity log rather than written from memory. Five calls, one user, the morning of 4 September 2026, all times UTC.
| Time (UTC) | Tool | Result |
|---|---|---|
| 05:35:12 | get_incidents | the failure classes, split into what needs action and what is third-party noise |
| 05:35:18 | get_incident_detail | the signature behind one of those classes, with the page it happens on |
| 05:38:07 | get_conversions | refused. The call named no domain the token owns, so the server answered domain_denied |
| 05:38:37 | list_domains | which sites this token can actually see |
| 05:39:14 | get_conversions | conversions for the right domain, second attempt |
Keep the refused call in view, because it is the one that tells you the connection is safe to hand an agent. A token reaches the sites it owns and nothing else, and when the agent overstepped it got a flat domain_denied rather than a plausible-looking empty answer it might have reported as "no conversions". It then called list_domains, found out what it was allowed to see, and asked again.
Those first two calls are six seconds apart, and the second one has to be told which failure to expand. What is Model Context Protocol? works through why that matters and what the log can and cannot prove about it.
What the agent replied is not recorded, deliberately: askbowtie stores which tool ran, for which domain, for which user, and when, and keeps no transcript at all.
What to ask first
Open-ended questions work better here than precise ones, because the agent can see the whole surface and you cannot yet.
| Ask this | And you find out |
|---|---|
| how's the site doing? | the headline state, plus anything actually broken |
| which page leaks the most sessions? | top pages by exit rate, joined to conversions |
| did anything change after the last deploy? | errors and conversions before and after the timestamp |
| what am I ranking for that I did not expect? | Search Console queries, impressions, clicks and position |
If you would rather not improvise, ask for playbook. It returns the indexed procedures the server ships with, so the agent can follow a known-good route instead of inventing one.
When it looks like it is not working
Four failures cover nearly all of it, and none of them needs a support ticket.
| Symptom | Usually | Check |
|---|---|---|
| the agent says it has no tools | the client never completed the handshake | restart the client, then ask it to run tools/list |
| tools exist but every answer is empty | no events have arrived yet | load a page of your own site, then ask again |
your site is missing from list_domains | the tag is missing its real data-token | view source on your live page and compare with the dashboard, or verification has not run yet; the dashboard shows the claim state |
| a Google tool refuses | the connector was never linked | Settings, then Connectors, then one consent screen |
One thing to know before you conclude that nothing is being recorded. On WordPress your own logged-in browsing is excluded automatically, so run that check in a private window or signed out, or you will see no events and assume the tag is broken. Everywhere else your own visits count like anyone else's.
Running more than one site
Agencies and anyone running a small portfolio hit this on day two. One account holds as many sites as you like, and one connection reaches all of them, because the token is tied to the account rather than to a domain. Each site still gets its own tracker line with its own data-token, and its own database behind the scenes.
What changes is how you ask. With one site connected, "how's the site doing?" is unambiguous. With four, the agent calls list_domains first and then either asks you which one you meant or answers for each in turn, so naming the domain in your question saves a round trip.
What the connection can and cannot see
A token reaches the sites it owns and nothing else, and each site's data sits in its own database. Tracking is cookieless by default.
In the other direction, askbowtie records which tool ran, for which domain, for which user, and when, and keeps no transcript of your prompts or the answers.
The one thing the connection does that a local server cannot is keep running after you close the chat. That is why a funnel break or an outage can reach a human at 2am, when no agent is asking anything.
Where to go next
Once the connection is live, the interesting question is not how to wire it up but what to point it at. The next pages cover which MCP servers reach a live website at all, and why an agent reading joined data beats an agent reading a dashboard.