Guides11 min read
Using an MCP Server to Run GEO Fixes From Your AI Agent
How to connect an MCP server to Claude, Cursor or ChatGPT, pull an AI visibility gap, and ship the fix as a GitHub pull request or CMS draft you approve.
David Andersen
Co-Founder & CTO
An MCP server lets an AI agent such as Claude, Cursor or ChatGPT call a product's tools directly from the conversation. BrandViz.AI's MCP server lets that agent read your AI visibility gaps, queue fixes and start Engine jobs, and every job that builds something ends as a pull request on a brandviz-agent/ branch or an unpublished CMS draft that a person on your team approves.
The latest report is open, one buyer question has ChatGPT recommending someone else, and Cursor sits in the next window on your site's repo. The usual next move is to copy the finding into a ticket and wait for someone to turn it into schema and a page. This guide shows the same job done from inside the agent with the BrandViz.AI MCP server, with the approvals marked along the way so nothing reaches production on its own.
Setup is already written up in the MCP setup docs, so I've kept it to the two snippets you'll want in front of you. Most of this post is about what happens after you connect. I'll use one example gap throughout: an audit that flags missing structured data on a pricing page. It's a made-up example with placeholder names, and the tool names and behaviours around it are the real ones.
What MCP is and why SEO teams care about it
The Model Context Protocol (MCP) is an open standard for connecting AI assistants to outside tools and data. A server publishes named tools, a client such as Claude or Cursor lists them, and the assistant calls them mid-conversation with arguments you can read. The protocol's own site has the specification if you want it.
SEO and marketing teams care because of where the agent already sits. An agent in Cursor or Claude Code is next to the repo, and one connected to your CMS is next to the content, which is where nearly every GEO fix ends up: JSON-LD, metadata, a restructured page, a new piece. What that agent doesn't have is any idea what ChatGPT, Claude, Gemini and Perplexity currently say about you. Connect it to a server that does, and the finding and the fix are in the same conversation.
BrandViz.AI's server lets an agent do three kinds of thing. It can read your reports, citations, audits, tasks and connected repo or CMS, change what BrandViz.AI measures and how it writes, and file tasks or start jobs. It's a second way into the same product, with the same data and the same approvals as the app, and the MCP server page has the summary.
Dashboard-only monitoring versus an MCP-connected workflow
Dashboard-only monitoring shows you where the engines skip you and stops at the chart, while an MCP-connected workflow lets an agent act on the same finding inside your own repo or CMS. The tracking versus execution post covers the classes of platform in general; the table below is the narrower question of what changes when an agent is in the loop.
| Dashboard-only monitoring | MCP-connected workflow | |
|---|---|---|
| Where you see the gap | A chart or export in a separate tab | In the conversation you're already working in, with each answer stamped with the report it read |
| Who turns it into a fix | Someone copies the finding into a ticket or brief, then someone else builds it | The agent reads the finding and files the task or starts the job |
| Where the fix is made | By hand, in your repo or CMS, when the ticket is picked up | In your own repo or CMS, as a pull request on a brandviz-agent/ branch or an unpublished draft |
| What holds the line | Whoever owns the ticket | A pending task, then your normal code review or CMS publish step |
| Checking the result | Reopen the dashboard after the next scan | Ask the agent for movement across reports, and for a live spot check against the engines |
As I see it, the slow part is usually the handoff between finding and fix rather than the finding, which is why the agent matters. A dashboard is still the better surface for a board-level view and for people who don't live in an agent, and BrandViz.AI keeps its own app for them, with the same approvals behind it.
Connect your agent to the server
Every client is pointed at one address, https://mcp.brandviz.ai/mcp, and the first use sends you to BrandViz.AI to sign in and approve the connection. It's OAuth, so there's no API key to copy. In Claude Code it's one command, then /mcp inside the session to sign in:
claude mcp add --transport http brandviz https://mcp.brandviz.ai/mcpIn Cursor, paste this into ~/.cursor/mcp.json and sign in when it asks:
{
"mcpServers": {
"brandviz": {
"url": "https://mcp.brandviz.ai/mcp"
}
}
}Claude on web and desktop uses a custom connector, and ChatGPT uses a developer-mode connector with OAuth. Both are covered screen by screen in the setup docs.
Two things need to be true before the later steps work. Reading data works on every plan, but tasks and jobs need the Engine, and a job can only land somewhere if you've connected GitHub or a CMS under Integrations. If you don't have a brand in BrandViz.AI yet, a free AI search audit is the quickest way to get a report for the agent to read.
Name the brand by its slug in your first message, the short name in your BrandViz.AI address (acme in /b/acme). Your client shows the arguments of each call, and a slug tells you at a glance which brand a change is for.
Pull the gap that matters most
Start with a read-only question and say so in the prompt:
Using brandviz on acme: which buyer questions does ChatGPT skip us on in
the latest report, who does it recommend instead, and what does the latest
site audit say to fix first? Rank them. Don't change anything.An example prompt. Swap acme for your own slug.
The agent first checks which brands you have, then reads the scores overall and per engine, how they moved across recent reports and, question by question, whether you were present, which pages were cited and which rivals showed up. It can then pull the latest site audit's findings, with severity, effort and the tasks already filed, and the actions the report recommended. Each answer is stamped with the report it read.
Agents state things with a lot of confidence from very little, so ask yours to say which report id each claim came from and check one against the app before you act. In our example the audit comes back with missing Organization and FAQPage structured data on the pricing page as the top technical finding. That's the technical layer of the three we triage by (technical, your own content, off-site), and the gap to live fix walkthrough explains why the layer decides what gets built. The schema guide covers what those blocks should contain.
Turn the gap into a pending task
The tasks tool with action: "add" files a pending task and runs nothing. It sits on your Tasks board until someone approves it. Each task needs a title, a description, a task_type (site_optimise for technical fixes such as schema and metadata, content_draft for a page or post) and a brief. The brief is the only thing the writing agent sees, so a task without one runs on its title alone.
{
"brand_id": "acme",
"action": "add",
"title": "Add Organization and FAQPage schema to the pricing page",
"description": "The latest audit flags missing structured data on /pricing.",
"task_type": "site_optimise",
"brief": "Add Organization JSON-LD site-wide and FAQPage JSON-LD on /pricing. State only what the visible page states. Use plan names and prices exactly as shown.",
"page_url": "https://acme.example/pricing",
"destinations": ["github"]
}Illustrative arguments for the tasks tool: a placeholder brand and page, with the real field names.
destinations takes cms, github or ui, and draft_destination: "google_docs" writes the piece into a Google Doc for review instead. Leave both out and the task lands wherever your connections send a draft. Attach source material as Google Docs or uploaded brand documents rather than pasting it into the brief, because the job reads a Doc's open comments as well as its body.
For an open-ended request such as "what should we publish for the early-stage gaps", ask the agent to run run_job with the content_plan job type first. It proposes a set of pieces from your gaps and returns a plan plus pending tasks, writes nothing to your site and doesn't count toward your monthly allowance. Adding "file them but don't approve" to the prompt keeps the next step in your hands.
Approve the task and let the Engine open the pull request or draft
Approving a task starts its job, and that's the point where your monthly allowance is spent, so the response says so. You can approve on the Tasks board, or the agent can call tasks with action: "approve" if you've told it to. A site_optimise or content_draft job counts toward the allowance, which is around 8 items a month on Starter and around 30 on Growth.
On a GitHub-connected site the job opens a pull request on a brandviz-agent/ branch through the BrandViz.AI GitHub App, which can create branches and pull requests and never pushes to main. On a CMS it writes an unpublished draft, entry or staged change, depending on the platform. The GitHub integration page and the CMS integrations guide list what each platform accepts and where it lands.
To see what was built without leaving the conversation, job_changes returns the recorded artifacts, a change summary and the pull request, CMS or Doc links, with the full output left out unless you ask for it. branches lists branches with their open pull request and protection status, and given a branch name it returns the file stats, a patch for any one file, and with merge_preview the conflict analysis. For our example you'd ask the agent to show the diff of the pricing page schema file and read it against the visible page before moving on.
Review where the change lands, then merge or publish
The second approval is the one an agent can't do. For a pull request, a developer reviews the diff in GitHub code review under your branch protection and CODEOWNERS and merges it. For a CMS draft, someone opens it in the editor they already use and publishes it. Nothing goes live until that happens.
If the change needs work, ask the agent to run run_job with content_revise and your feedback. It edits the piece where it already lands, in the pull request, CMS entry or Doc, builds on the newest version and files no new task or allowance charge. You can also point the read-only branch_review job at any branch, including one a person on your team wrote. It reviews the changes for brand fit, claims and the head and crawl signals AI assistants read, counts nothing toward the allowance, and can post its result as a comment on the open pull request.
How to tell whether the fix moved anything
The measurement is the next report, not the agent's opinion of its own work. Ask the agent for movement across recent reports and per question, so the buyer question you started from in Step 2 is the row to look at once the pricing page schema is live. Our gap to live fix walkthrough puts the lag between a fix going live and its row moving at roughly 4 to 12 weeks across the sites we track, depending on how often each engine re-fetches the page and how contested the question is.
For a quicker look, the agent can put a question of your own to ChatGPT, Claude, Gemini and Perplexity live and check whether each assistant's own fetcher could open a page you name. Treat it as one sample of what they say today and leave the rate to the tracked reports.
What the agent does at each step, and what it costs
| Step | What the agent does | What it touches | Monthly allowance |
|---|---|---|---|
| 2. Pull the gap | Reads scores, questions, citations, audit findings and recommended actions | Reads your own reports | None |
| 3. File the task | Files a pending task, or asks for a content plan | A pending card on the Tasks board; nothing written to your site | None |
| 4. Build it | Approves the task, or starts a technical or content job | A pull request on a brandviz-agent/ branch, or an unpublished CMS draft | Counts |
| 4. Inspect it | Shows what was built, with the diff or the CMS entry | Reads the branch, the pull request or the CMS entry | None |
| 5. Revise or review | Revises the piece on your feedback, or reviews a branch | Edits the piece where it lands, or reads a branch and optionally comments on its pull request | None |
Last verified: 11 November 2026, against the MCP setup docs and the server's tool descriptions.
Security and approval controls
The short version is that the agent gets your permissions and nothing more, and that nothing it starts can reach production without a person. The lists below are the same permissions the sign-in screen shows before you approve the connection.
What a connected agent can do
- Read the brands your account can already open: scores, citations, audits, tasks, questions and the connected repo's branches
- Change what a brand measures and how it writes: questions, markets, aliases, brand profile and lessons
- File content tasks, approve them or dismiss them
- Start content jobs that end as a pull request or a CMS draft
- Ask the live assistants a question or read a public web page
What it can't do
- Publish anything: a job's output always stops at a pull request or a draft
- Push to main or delete your posts, pages, entries, files or branches
- Reach a brand your account can't already open
- See or change billing, plan limits, team members or a stored integration credential
- Delete a brand, a report or a question's history
Sign-in and scope
The agent signs in as you through OAuth, so its reach is exactly your account's reach and there's no long-lived key sitting in a config file. The connected app is listed under Settings → AI assistants with when it was last used, and removing the connector in the app that holds it cuts that app off without touching your other connections. Pull requests and drafts already delivered stay where they are, because they belong to your site.
Two approval gates
The first gate is the task. Adding one runs nothing, approving one starts the work and spends allowance, and dismissing one has no undo. You can approve on the Tasks board or let the agent do it, which is a choice about how much you trust your prompt. The second gate is the change itself, and it sits in your own tools: code review on the pull request, or the publish button in your CMS. The Engine's integrations hold the narrowest access their platform offers for drafting and nothing for publishing, and the agent has no way to move the second gate.
What your client sees
Every tool carries the standard MCP hints saying whether it only reads, changes settings, or does something that can't be undone. The tasks tool carries the destructive hint because the worst thing it can do is dismiss a task, and run_job is marked as reaching outside BrandViz.AI and unsafe to repeat, since two identical calls start two jobs. Clients use those hints to decide when to ask you, and many let you allow read-only tools once while still asking for the rest, so how yours behaves is a setting in the client. The live reads, ask_assistants and read_site, are capped per hour, refuse private network addresses, and nothing they return is stored as report data.
Compliance
BrandViz.AI doesn't have a SOC 2 report yet. For enterprise customers we complete security reviews and sign DPAs, and if your procurement team needs something specific for an agent connection, the quickest route is to talk to us before you connect a production brand. The wider BrandViz.AI platform page shows where the MCP server sits next to the audit, the Engine and the integrations.
Frequently asked questions
What can an AI agent do through the BrandViz.AI MCP server?
An agent connected to the BrandViz.AI MCP server can read your visibility scores, citations, audit findings and recommended actions, change what BrandViz.AI measures, file and approve content tasks, and start Engine jobs. It cannot publish. Every job that builds something ends as a pull request on a brandviz-agent/ branch or an unpublished CMS draft that a person on your team approves, and planning jobs only propose and write nothing to your site.
Can the agent publish changes to my site?
No. Any job that builds something through the MCP server delivers a pull request on a brandviz-agent/ branch, never a push to main, or an unpublished draft in your connected CMS. A person on your team merges the pull request or presses Publish. The server also cannot delete a brand, a report or a question’s history.
Do I need an API key to connect?
No. The server uses OAuth sign-in with your BrandViz.AI account, so your agent signs in as you and can reach only the brands your account can already open. There is no key to copy or store. Once connected, the app appears under Settings → AI assistants in BrandViz.AI with the time it was last used.
Which AI agents and plans work with the MCP server?
Claude on web and desktop, Claude Code, Cursor and ChatGPT work, as does any MCP client that supports remote servers with OAuth sign-in. Reading your visibility data works on every plan. Tasks, audits and jobs need the Engine: Starter is A$200 (US$149) a month with around 8 items shipped, and Growth is A$1,000 (US$699) a month with around 30.
Does it work if our site is not on GitHub or a listed CMS?
The agent can still read your gaps and file tasks. A task can be set to write its piece into a Google Doc for review, and platforms BrandViz.AI does not connect to receive the same fix as a brief with the copy, the JSON-LD and where each piece goes. If your site lives in a GitHub repository, the GitHub integration covers it directly.
Can the agent change what BrandViz.AI tracks?
Yes. The setting tools let an agent change a brand’s questions, markets, competitor regions, alias names, brand profile and lessons, and those changes take effect on the next report and the next job. None of them touches your site. Ask the agent to describe a change before it makes one, because the scope is the brand’s whole measurement set.
Is the MCP server SOC 2 certified?
No. BrandViz.AI does not have a SOC 2 report yet. For enterprise customers we complete security reviews and sign DPAs, so if your procurement team needs either for an agent connection, raise it before you connect a production brand.