Connect Claude or ChatGPT to your SEO data with MCP
Maark ships a hosted MCP server, so Claude, ChatGPT or Cursor can read your Keyword Universe and propose changes — scoped to the projects you choose, previewing by default, and never able to publish to your site.
Maark teamAI connections, MCP, IntegrationsUpdated
The most natural interface to your SEO data might be the assistant you already talk to all day. Instead of learning a dashboard's every corner, you ask Claude "which of my clusters has no page yet?" and it answers from your actual data — then, if you let it, proposes what to do about it.
Maark makes that real through MCP, the Model Context Protocol: a standard way for an AI client to connect to an external tool server. We host the server. You add Maark as a connector in your client. There is nothing to install and nothing to run.
This post is the whole picture: how the connection is shaped, what your assistant can and cannot do, and where the authority ceiling sits.
How the connection works
The endpoint is the same everywhere — a single hosted URL your assistant talks to over streamable HTTP. There are two ways to authenticate, matched to how each client prefers to connect:
- A scoped key (it looks like
mk_…) for Claude Code and Cursor. You mint it once in your org settings, paste it into the client, and that is the connection. - A guided sign-in (OAuth) for claude.ai and ChatGPT — add Maark as a custom connector, approve it in a browser, and there is no key to copy. It uses OAuth 2.1 with PKCE, the modern, phishing-resistant flavour.
Once connected, your assistant sees 59 tools — filtered down by the scope on the connection, which we will get to. They cover the ground you would otherwise be clicking through:
| What you want to know | What the assistant reaches for |
|---|---|
| Which topics have demand but no page | find_content_opportunities, get_cluster_page_candidates |
| Why a cluster is mapped where it is | explain_cluster_mapping, get_mapping_evidence |
| What the pipeline is actually doing | get_keyword_pipeline_status, get_enrichment_job |
| What the brand stands for and sells | get_brand_dna, get_brand_context, search_brand_memory |
| Which internal links point at dead pages | find_dead_link_targets |
| What is on the plan this quarter | get_campaign_plan |
The reads are the part people underestimate. Most SEO questions are not "make a change" — they are "what is true right now, and why does the tool think that?". Being able to ask that in the same window where you are already working is most of the value, before any write tool enters the picture.
Scopes: read, propose, operate
Every connection carries exactly one scope, and it decides what the assistant is allowed to do.
- Read — look, never touch. Every read tool, no writes.
- Propose — the assistant can draft changes, but write actions are clamped to a preview. It shows you what it would do; approvals still happen in Maark.
- Operate — the assistant can make real changes to your Keyword Universe: map a cluster to a page, move keywords between clusters, split a cluster, exclude off-scope terms.
There is a real authority ceiling here, not just a setting. A non-admin member of your org can only be granted read; propose and operate require an org admin to grant them. And even at operate scope, write actions default to a safe preview — to actually write, the assistant has to explicitly confirm, so a stray request cannot quietly mutate your data.
That default matters more than it sounds. An assistant asked to "clean up the universe" will happily interpret that generously. The preview is the step where generosity becomes a diff you can read before it is a change you have to undo.
What it cannot do — by construction
This is the part we want to be unambiguous about, because "connect your AI to your data" makes people picture an agent with the keys to everything.
- It cannot publish to your site. Publishing always goes through the human review flow. There is no MCP tool that pushes anything live, at any scope.
- It cannot approve its own proposals. When the assistant suggests a mapping change or a new page, that lands as a proposal or an opportunity — a recommendation a human approves in Maark. The tool that grades and approves proposals is deliberately not on the connection at all, so an assistant cannot self-approve.
- It cannot wander into your other projects. A connection reaches only the specific projects you enable for it. A project that is not enabled for external access is invisible — and asking about it returns the same "not found" as a project that does not exist, so the connection cannot even be used to probe what else you own.
Some tools are absent from the connection on purpose, too. Our internal work-vocabulary tools and the agent-facing notes vault are not in the customer manifest and never will be: they carry no project scope, which puts them outside the per-project consent boundary everything else is gated on. A test in our own build fails if anyone adds them.
Connections are rate-limited, and every action taken over one is recorded — so you always have a trail of what ran, when, and under which scope.
Setting it up
The specifics per client live in the AI connections help articles, but the shape is the same everywhere:
- Enable the project. External agent access is opt-in per project, under Limits & Quotas → External agent access in project settings. Nothing is reachable until you turn it on.
- Mint a key, or connect by OAuth. Keys live in Org Settings → AI Connections. Pick the scope deliberately — start at read.
- Add Maark in your client. Paste the key, or approve the browser sign-in.
- Ask it something you already know the answer to. This is the step people skip. Ask about a cluster you understand, and check the answer against what Maark shows you. You are calibrating trust, and it takes one question.
Where this changes the work
Three patterns have come out of running it on our own project and our clients':
Interrogating a recommendation. Maark says a cluster should map to a page. explain_cluster_mapping says why — the rank evidence, the title match, the page type. In a dashboard that is a drilldown you may not bother opening. In chat it is the obvious next question, so you ask it, and you catch the wrong ones.
Bulk judgement with the tedium removed. Reviewing two hundred keywords for relevance is a job humans do badly by hour three. Asking an assistant to walk them against your brand context, propose exclusions and show you the list is a job it does evenly at hour three. You still approve the list.
Working where the context already is. In Claude Code with the repo open, the assistant holds the site and the SEO data in one conversation. "This cluster has no page — what would it look like against our existing components?" is not a question a dashboard can be asked.
The mental model
Think of it as handing your assistant a library card, not the keys to the building. It can read everything on your shelves, it can fill out a request slip for a change, and with the right card it can reshelve within the room you pointed it at — but it cannot walk into the next room, and it cannot publish a book with your name on the cover.
You stay the editor. The assistant gets very good at telling you what is actually on the shelves.
The Keyword Universe post explains the data your assistant is reading, and how the editorial gate works covers the review flow every published change still passes through.
Read next