Agentic SEO With MCP: Wiring Claude Code and Cursor to Live Visibility Data

Most SEO work inside a coding agent still starts with a paste. You copy a table out of a dashboard, drop it into the chat, and ask the agent to make sense of it. The Model Context Protocol removes that step. Instead of handing the agent a stale snapshot, you hand it a live tool it can call. The agent reads the current visibility data, reasons about it, and writes the next action back through a controlled surface.

This guide wires Claude Code and Cursor to the Promptwatch MCP server and runs a first loop that ends in a real write. The setup is short on purpose. The interesting part is the authority model, not the config.

What you need first

You need a Promptwatch account and an API key. The hosted server lives at https://server.promptwatch.com/mcp and speaks streamable HTTP over OAuth or a Bearer key. The same server backs the ChatGPT plugin and the Claude connector, so anything you build here also works in those clients.

Make two keys if your account allows it. One read-only key for scheduled and exploratory work, and one write key for the narrow loop you actually trust. The read-only key hides the write tools from the client entirely, which is the property that makes an agent safe to leave running. You will use the read-only key for everything in this guide except the final publish step.

Connecting Cursor

Cursor reads MCP servers from .cursor/mcp.json at the root of your project. Create the file if it does not exist and add the Promptwatch server. The shape is straightforward.

{
  "mcpServers": {
    "promptwatch": {
      "url": "https://server.promptwatch.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_READ_ONLY_KEY"
      }
    }
  }
}

Restart Cursor or reload the MCP list from the settings pane so the server appears. Open a chat in agent mode and ask it to list the available tools. You should see the read tools, listPrompts, getVisibilityTimeSeries, getCitations, getCrawlerTrend, and the rest, with no write tools present. If you see createContent or publishContentLive, you connected the write key by mistake. Swap it for the read-only key before you go further.

Connecting Claude Code

Claude Code reads the same server shape from its own config. You can add the server with the CLI.

claude mcp add promptwatch --transport http https://server.promptwatch.com/mcp \
  --header "Authorization: Bearer YOUR_READ_ONLY_KEY"

Run claude mcp list to confirm the server is registered and reachable. Start a session and ask Claude Code to describe the tools it can see. The same check applies. A read-only key should expose the read surface and nothing that mutates state. Keep the write key out of the agent config until you have a loop you want to gate behind a human approval.

A first read loop

Start with a question a tracker would answer, and let the agent answer it from live data. Ask: which tracked prompts lost visibility this week, and what changed in the answers?

The agent has the tools to do this properly. It calls listPrompts to get the tracked set, then getVisibilityTimeSeries for each prompt to find the ones that moved. For a prompt that dropped, it calls getPrompt to read the current answer and getCitations and getCitationTopPages to see who is being cited instead. getCompetitorHeatmap shows whether the loss is yours alone or a category shift. listQueryFanouts exposes the related prompts around the seed query, which often reveals the real query the answer shifted toward.

What you get back is a diagnosis grounded in current data, not a guess. The agent can name the prompt, the competitor that took the citation, and the page they were cited for. That is the evidence half of an acting workflow.

Adding the write half behind a gate

Once the diagnosis is reliable, you can let the agent propose work. With the read-only key, it can call listContentGapPrompts and getContentGapRecommendations to find the prompts you are missing, then draft a content plan. It can call listActionItems to read the queued work and getSiteHealth for structural context. None of that mutates state.

The write half needs the write key and a human checkpoint. Swap the key in your config, or keep a second server entry with the write key that you only enable for the publish step. The agent then calls createContent to draft from the gap, listContentSlots to read the review inbox, and acceptContentSlot to move a draft forward. The final call, publishContentLive, pushes the approved draft to the connected CMS. Treat that one call as the boundary. Everything before it is reversible. The publish is the point where the work leaves the platform and reaches your site.

A reasonable pattern is to keep the read-only server in the config permanently and add the write server only for the publish session, then remove it. That way a scheduled or exploratory agent literally cannot publish, because the tool is not present.

A concrete weekly loop

Here is a loop you can run every Monday with one agent session. Read the visibility time series for the tracked prompts. Find the three that moved most. For each, pull the citations and the competitor heatmap. Draft a one-paragraph diagnosis per prompt. Call createActionItem for each prompt with the diagnosis and a suggested next step, and updateActionItemStatus to set them to open. End the session.

You have not published anything. You have not changed the site. You have turned a week of visibility data into three owned, evidence-backed tasks on the action board, and a human can pick them up or close them. That is the smallest useful acting loop, and it ran entirely over MCP against live data.

Where this goes next

Once the read loop is trusted, the natural next steps are a content loop that ends in a published article and a crawler loop that ends in a robots.txt fix. Both follow the same shape. Read the evidence with the read-only key, propose the change, then gate the write behind a human and the write key. The Promptwatch MCP server exposes the tools for both, which is why it is the practical backbone for agentic SEO work in a coding agent. Start read-only, keep it that way for as long as you can, and only widen the key when you have a loop worth trusting.