Building an SEO MCP server for Claude Code and Codex

Most SEO APIs were built for dashboards.

That is not a criticism. Dashboards are useful. A marketer opens a report, checks rankings, reviews keywords, exports a CSV, and decides what to do next.

But that is not how work feels inside Claude Code, Codex, Cursor, or a custom AI agent.

Inside an agent workflow, the shape is different. You do not want to stop, open a separate SEO tool, copy data into the chat, ask the model to reason over it, then move back to your editor.

You want the agent to ask for live search data directly.

That is why we shipped AgentSEO as an MCP server.

This post is a practical breakdown of what changed, how the server is installed, and why I think SEO APIs are going to move from dashboard-first products to agent-native workflow tools.

The buyer problem is not only data access

SEO teams already have data.

They have rank trackers, backlink tools, keyword databases, crawl reports, and a growing pile of AI visibility screenshots. The problem is that the data often stops one step before the work.

A typical SEO API gives you a payload.

Then your team still has to answer:

• Which result matters?
• Which page should we update first?
• What is the intent behind this SERP?
• What should the writer or developer actually change?
• Is this useful for an agent, or does it need another parser layer?

That last question is the one more API teams should ask.

If the output still needs a parser layer, a polling layer, and a summarization layer before an agent can act, the API is not finished for agent workflows.

What an SEO MCP server should do

MCP gives clients a standard way to discover and call tools. The official MCP registry describes itself as a list of MCP servers for clients, like an app store for MCP servers.

That matters because the install surface is moving closer to the place where developers already work.

For SEO, I do not think the best MCP server is just a thin wrapper around raw endpoints. That is a start, but it misses the point.

A useful SEO MCP server should expose workflow-shaped tools.

Instead of only returning raw SERP data, it should help an agent do jobs like:

• analyze SERP intent
• find content gaps
• draft a content brief
• check local visibility
• review title and meta opportunities
• inspect AI Overview presence
• identify backlink opportunities
• QA a draft before publishing

The agent should be able to move from question to action without making the user become the integration layer.

What we built into AgentSEO

AgentSEO now exposes 45 MCP tools for live SEO workflows.

The tools cover:

• SERP analysis
• keyword research
• content briefs
• content refresh briefs
• backlink analysis
• rank tracking
• local SEO checks
• sitemap and technical QA
• AI Overview extraction
• AI search visibility monitoring

The important part is not the number. A big tool count can become noise fast.

The important part is that the tools map to repeatable SEO jobs. A developer, growth engineer, or technical SEO should be able to give the agent a real task and get back something useful enough to act on.

Example:

Use AgentSEO to analyze the SERP for "best seo api" in the United States.
Identify the dominant intent, list the strongest competing angles,
and create a content brief for a comparison page.

That is different from:

Fetch the SERP payload and make me figure out the rest.

The second version is data access. The first version is closer to workflow infrastructure.

Install path: hosted MCP

For clients that support remote MCP servers, AgentSEO can run over hosted Streamable HTTP.

claude mcp add --transport http agentseo https://www.agentseo.dev/mcp \
  --header "Authorization: Bearer sk_live_your_key" \
  --header "x-project-id: client-alpha" \
  --header "x-workflow-id: nightly-refresh"

The extra headers are optional workflow metadata. I like keeping them in the example because production agent workflows need traceability. When an agent calls a paid or rate-limited API, you eventually want to know which project and workflow made the call.

Install path: local stdio MCP

For local MCP clients, the npm package works through stdio.

{
  "mcpServers": {
    "agentseo": {
      "command": "npx",
      "args": ["-y", "@agentseo/mcp-server"],
      "env": {
        "AGENTSEO_API_KEY": "sk_live_your_key",
        "AGENTSEO_API_URL": "https://www.agentseo.dev/api/v1"
      }
    }
  }
}

That gives teams a clean local path without forcing every client through the hosted endpoint.

The GTM lesson: MCP directories are becoming agent app stores

The product work was only half the launch.

The other half was distribution.

If you ship an MCP server and only mention it in your docs, you are making discovery too hard. Developers are already browsing MCP directories to find tools their agents can use.

For AgentSEO, we published or submitted to:

Surface	Status
Official MCP Registry	Live as dev.agentseo.www/agentseo-mcp
npm	Live as @agentseo/mcp-server
Smithery	Live, 45 tools detected
Glama	Hosted connector live, 45 tools verified
mcp.so	Submitted
awesome-mcp-servers	PR submitted
PulseMCP	Waiting on official registry sync
MCP Market	Submitted
MCP Server Spot	Submitted

This is the new shelf space.

Not all of it will convert. Some directories will send little traffic. Some will take weeks to index. Some will matter mostly as trust signals.

But the intent is unusually clean.

Someone browsing an MCP directory is not vaguely interested in AI. They are looking for a tool their agent can install.

That is a better starting point than most launch traffic.

The product lesson: expose jobs, not endpoints

This is the part I would underline for any API company.

Do not start by asking, "How do we expose every endpoint through MCP?"

Start with a smaller question:

What are the 5 jobs an agent should be able to complete without leaving the workflow?

For an SEO API, those jobs might be:

1. Analyze a live SERP.
2. Find keyword or content gaps.
3. Create an implementation-ready brief.
4. QA a draft before publishing.
5. Track whether visibility moved.

That is enough for a useful first version.

The raw endpoint map can come later. If you start with the endpoint map, you risk shipping a server that is technically complete and practically annoying.

A simple checklist for API teams

If you are thinking about turning your API into an MCP server, I would start here:

• Pick one user: developer, agency operator, growth engineer, analyst.
• Pick one repeatable workflow.
• Expose the few tools needed to complete that workflow.
• Make the install command copy-pasteable.
• Publish to the official MCP registry.
• Add one directory listing where your buyers already browse.
• Test with a real prompt, not only a protocol inspector.

The inspector can tell you the server works.

A real prompt tells you whether the product works.

The larger shift

APIs used to feed dashboards.

Now they can feed agents.

That does not make dashboards obsolete. It does mean API products need a second interface: one designed for software agents that can plan, call tools, inspect results, and continue the workflow.

For AgentSEO, MCP is that interface.

The bet is simple: if AI agents are where more technical SEO and growth work happens, then SEO infrastructure should be available inside those agents.

Not as a pasted export.

As a tool the agent can actually use.

Links

• AgentSEO MCP landing page: https://www.agentseo.dev/seo-mcp-server
• AgentSEO quickstart: https://www.agentseo.dev/docs/quickstart
• npm package: https://www.npmjs.com/package/@agentseo/mcp-server
• Official MCP registry docs: https://github.com/modelcontextprotocol/registry/tree/main/docs
• Glama connector: https://glama.ai/mcp/connectors/dev.agentseo.www/agentseo-mcp
• Smithery listing: https://smithery.ai/servers/agentseo/agentseo-mcp