Fix what AI search gets wrong about you, from Claude Code (MCP)

A dashboard can tell you that three hundred of your pages point their canonical somewhere else. It cannot open the template and fix it. An assistant running in your repository can do both, if it can read what the dashboard knows. That is what our MCP server is for, and this is the loop we use it for: read the findings, change the code, mark the work done, and let the re-measure say whether it moved anything.

What the server is

MCP — the Model Context Protocol — is the standard way for an assistant such as Claude, ChatGPT or Codex to call tools outside itself. Ours lives at https://api.recomma.ai/mcp. Every tool on it calls the same procedures the product's own screens call, so a connection sees exactly what the person who made it sees, in the workspace they have open, and nothing from any other.

Reading is what a connection gets by default. Changing anything is a second permission, granted separately, and every change previews before it applies. Two pieces of reference ride along with the tools — a glossary of every term the figures use, and the method behind the market-value numbers — so an assistant can look up what "visibility" or "sample" means here before it explains a figure to you, rather than guessing.

It is not the only MCP server in this category, and it does not need to be. What it is built around is the part of the product that ends in a change you can make: the site audit, whose findings come with the markup as it is and as it should be, and the action queue, whose tickets are re-measured after they close.

Connect your client

The shortest path is in the app, under Settings → Connect AI: pick a client and it gives you that client's one-step install. For reference, here is what each one is.

For Claude Code, which is where the rest of this post happens:

claude mcp add --transport http --scope user recomma https://api.recomma.ai/mcp

The first call opens a browser. You sign in as usual, and a consent screen says what is being connected and what it may read. Approve it and the client has a token; the connection then appears under Connected apps on the same settings page, where disconnecting it stops its very next call. If you belong to several workspaces, the connection follows whichever one you last had open in the app.

The tools, read and write

Nineteen tools in all. Fifteen read; four write. The reads cover the same ground as the product's pages:

The four writes are create_prompts and suggest_prompts, which propose new questions to track; set_prompt_status, which starts or pauses sampling them; and set_action_status, which moves a ticket on the queue. Every figure a read returns carries the number of answers behind it, and a question nothing has sampled yet comes back as null rather than zero — "we have not looked" and "they never name you" are opposite findings, and an assistant should not be able to confuse them.

The loop: findings to verdict

Open Claude Code in the repository your site is built from, and work through it in this order.

• Find the brand. list_brands returns the id every other tool takes, and whether this connection may write.
• Read what fails. get_site_findings with no rule lists every audit rule the site fails, with how many pages each touches and how much of the site has been read so far. A partial crawl is a true statement about the pages read, and the tool says how many.
• Pick one rule and get the diff. Called again with rule, it returns the failing pages with before and after: the markup as it is and as it should be, plus the steps to get there. Where after is null, the fix needs a person to write something, and the assistant should say so rather than invent it.
• Fix the template, not the page. A rule failing on a large share of pages is nearly always one line in a layout file. Ask the assistant to find it, change it, and show you the diff before you ship.
• Close the ticket. list_actions with kinds: ["owned_audit"] finds the ticket for that rule. set_action_status moves it to in_progress while the work happens and to done once it is live — previewing first, then applying.
• Wait for the verdict. Marking done freezes the current reading on the questions the ticket targets and schedules a re-measure two weeks later. get_impact reports it as pending until then, and as a verdict after — kept whichever way it went.

The fourth step is the one a dashboard could never take, and the sixth is the one that keeps the rest honest. A fix that changed nothing is worth knowing about, and a queue that only ever reports progress is a queue nobody should believe. We wrote about why the verdict is kept in every gap becomes a ticket.

What a write cannot do

An assistant in a loop can call a tool twenty times in thirty seconds, so the writes are built for that caller:

• Writes need the recomma:write scope, which a client asks for separately. A connection that may only read and calls a write gets a challenge naming the missing scope — which a client that supports it turns into a second approval, not a failure.
• Every write previews by default and changes nothing until it is called again with apply: true.
• New questions land as suggested. Nothing is sampled, and nothing spent, until a person accepts them on the Prompts page.
• Activating questions spends the plan's allowance, so the preview says how many runs a week it would start — and a call that would commit more than half of what the plan has left is refused and left to a person.
• A ticket already done is never re-marked or reopened: that would overwrite or discard the reading frozen when it closed. That call belongs to a person, on the Impact page.
• Nothing deletes.

Ready-made workflows

Clients that support MCP prompts will also list five workflows, each a sequence of the calls above with the rules for reading what comes back:

site_fix_plan is the loop above written down. It reads and reports and edits nothing unless you ask — and when you do, it starts with the template faults. The rules it works from are the fifteen in our GEO audit checklist.