Programming /

The_MCP_Server_Is_The_Product

# The MCP Server Is the Product > I asked Claude to do keyword research by pointing it at the DataForSEO MCP server. It returned a confident, plausible list of search volumes. About a third of them were invented. The right answer was not "trust the agent less." The right answer was "give the agent a place to save its work, so I can check." ## Key Takeaways - OpenSEO exposes a Model Context Protocol server at `https://app.openseo.so/mcp` and ships **seven pre-built agent skills** (`seo-project-setup`, `seo-coach`, `keyword-research`, `keyword-clustering`, `competitive-landscape`, `competitor-analysis`, `link-prospecting`). - The interesting design choice is not the MCP server — that is just a transport. The interesting choice is that the agent can **save its work back to a project in OpenSEO**, so the user can inspect the data, not the agent's report about the data. - The `seo-coach` skill is the one that changes the trust model. It reads from a per-project "Project Context" artifact — a markdown document the onboarding agent wrote — and reasons against that artifact, not against a fresh LLM guess. - The combination — MCP for tools, skills for *what to do with the tools* — is the actual product. The dashboard is the inspector. The agent is the worker. --- I want to start with a confession. The first time I pointed an AI agent at the DataForSEO MCP server, I got back a list of 200 keyword ideas with search volumes attached. The agent summarized the top ten. The summary was clean, structured, the kind of thing you would have paid a junior SEO $400 to produce. Then I spot-checked ten of the volumes against the DataForSEO web UI. Six matched. Three were off by a small but material amount. One was a number I am fairly sure the model invented because the *shape* of the distribution was right but the actual value did not exist in the source. The agent had not lied to me. The agent had done exactly what I asked. It had returned a confident summary of plausible-looking data, and the data was the data, and I had no way to know which parts of the data were real and which parts were a language model's best guess at what real data would look like. The trust model was broken in a way that is hard to describe unless you have lived it. The fix is not "trust the agent less." The fix is to give the agent a place to *save* its work, so the human can check the work instead of the report about the work. That is the design decision OpenSEO made, and it is the most important one in the project. ## The MCP server is a transport Let me be clear about what an MCP server is, in case the term is new. Model Context Protocol is a standard for letting an LLM agent call external tools. The server advertises a list of tools, the agent reads the list, the agent picks the tools it wants to use, the agent calls the tools, the tools return data, the agent reasons about the data. The transport is JSON over HTTP or stdio. The protocol is open. The standard is governed by Anthropic and adopted by every major agent framework. OpenSEO's MCP server is at `https://app.openseo.so/mcp`. The setup is one command in Claude Code: ```bash claude mcp add --transport http --scope user openseo https://app.openseo.so/mcp ``` The first connection runs you through OpenSEO's OAuth login. After you authorize, your agent can call any of the MCP tools. The list, from the project's public documentation, includes tools for keyword research, SERP inspection, local business research, competitive search intelligence, domain research, backlink overview, saved keywords, rank tracking, and — for self-hosters with their own Google OAuth client — Google Search Console performance and URL inspection. There are 15 tools in total. Each one maps to a feature in the dashboard. That is the transport. The interesting part is what the agent does with the tools. ## The seven skills OpenSEO ships seven pre-built agent skills, in the `web/content/docs/skills/` directory of the repository. Each one is a `SKILL.md` (or `.mdx`) file the agent reads at the start of a session to learn what to do. The list, in alphabetical order: - `seo-project-setup` — captures the user's SEO goals, target audience, and website context in a local workspace before any research begins. - `seo-coach` — answers SEO questions and OpenSEO product questions, reading from the project's "Project Context" artifact. - `keyword-research` — discovers keyword opportunities, organized by intent and difficulty. - `keyword-clustering` — turns a flat list of keywords into page groups with shared intent. - `competitive-landscape` — maps a market before choosing competitors, identifying the SERP archetype for each query class. - `competitor-analysis` — studies one competitor: their keywords, content, backlinks, and ranking patterns. - `link-prospecting` — finds outreach prospects for a linkable asset, ranked by relevance and authority. These are not tools. They are workflows. Each skill is a multi-step procedure the agent follows, calling MCP tools as it goes. The skill i

Chapter 4 of 5 9m Article Learning path

The MCP Server Is the Product

I asked Claude to do keyword research by pointing it at the DataForSEO MCP server. It returned a confident, plausible list of search volumes. About a third of them were invented. The right answer was not "trust the agent less." The right answer was "give the agent a place to save its work, so I can check."

Key Takeaways

OpenSEO exposes a Model Context Protocol server at https://app.openseo.so/mcp and ships seven pre-built agent skills (seo-project-setup, seo-coach, keyword-research, keyword-clustering, competitive-landscape, competitor-analysis, link-prospecting).
The interesting design choice is not the MCP server — that is just a transport. The interesting choice is that the agent can save its work back to a project in OpenSEO, so the user can inspect the data, not the agent's report about the data.
The seo-coach skill is the one that changes the trust model. It reads from a per-project "Project Context" artifact — a markdown document the onboarding agent wrote — and reasons against that artifact, not against a fresh LLM guess.
The combination — MCP for tools, skills for *what to do with the tools* — is the actual product. The dashboard is the inspector. The agent is the worker.

---

I want to start with a confession. The first time I pointed an AI agent at the DataForSEO MCP server, I got back a list of 200 keyword ideas with search volumes attached. The agent summarized the top ten. The summary was clean, structured, the kind of thing you would have paid a junior SEO $400 to produce. Then I spot-checked ten of the volumes against the DataForSEO web UI. Six matched. Three were off by a small but material amount. One was a number I am fairly sure the model invented because the *shape* of the distribution was right but the actual value did not exist in the source.

The agent had not lied to me. The agent had done exactly what I asked. It had returned a confident summary of plausible-looking data, and the data was the data, and I had no way to know which parts of the data were real and which parts were a language model's best guess at what real data would look like. The trust model was broken in a way that is hard to describe unless you have lived it.

The fix is not "trust the agent less." The fix is to give the agent a place to *save* its work, so the human can check the work instead of the report about the work.

That is the design decision OpenSEO made, and it is the most important one in the project.

The MCP server is a transport

Let me be clear about what an MCP server is, in case the term is new. Model Context Protocol is a standard for letting an LLM agent call external tools. The server advertises a list of tools, the agent reads the list, the agent picks the tools it wants to use, the agent calls the tools, the tools return data, the agent reasons about the data. The transport is JSON over HTTP or stdio. The protocol is open. The standard is governed by Anthropic and adopted by every major agent framework.

OpenSEO's MCP server is at https://app.openseo.so/mcp. The setup is one command in Claude Code:

claude mcp add --transport http --scope user openseo https://app.openseo.so/mcp

The first connection runs you through OpenSEO's OAuth login. After you authorize, your agent can call any of the MCP tools. The list, from the project's public documentation, includes tools for keyword research, SERP inspection, local business research, competitive search intelligence, domain research, backlink overview, saved keywords, rank tracking, and — for self-hosters with their own Google OAuth client — Google Search Console performance and URL inspection. There are 15 tools in total. Each one maps to a feature in the dashboard.

That is the transport. The interesting part is what the agent does with the tools.

The seven skills

OpenSEO ships seven pre-built agent skills, in the web/content/docs/skills/ directory of the repository. Each one is a SKILL.md (or .mdx) file the agent reads at the start of a session to learn what to do. The list, in alphabetical order:

seo-project-setup — captures the user's SEO goals, target audience, and website context in a local workspace before any research begins.
seo-coach — answers SEO questions and OpenSEO product questions, reading from the project's "Project Context" artifact.
keyword-research — discovers keyword opportunities, organized by intent and difficulty.
keyword-clustering — turns a flat list of keywords into page groups with shared intent.
competitive-landscape — maps a market before choosing competitors, identifying the SERP archetype for each query class.
competitor-analysis — studies one competitor: their keywords, content, backlinks, and ranking patterns.
link-prospecting — finds outreach prospects for a linkable asset, ranked by relevance and authority.

These are not tools. They are workflows. Each skill is a multi-step procedure the agent follows, calling MCP tools as it goes. The skill is the recipe. The MCP tools are the ingredients.

A concrete example. The keyword-research skill does not just call research_keywords and return the result. It does this, roughly:

1. Read the project context to understand the site, the audience, and the goals. 2. Generate 5–10 seed keywords from the project context. 3. Call research_keywords for each seed at 150 results. 4. Read the results, filter for relevance and difficulty, deduplicate. 5. Cluster the surviving keywords by intent and SERP archetype. 6. Save the clusters back to the project with names the user can recognize. 7. Hand the user a link to view the clusters in the OpenSEO dashboard.

The agent does not invent the cluster names. The agent does not invent the relevance filter. The agent does the work the skill describes, with the MCP tools as primitives. The dashboard is where the user goes to *see* the work.

The "Project Context" artifact

The piece I underestimated on first read is the *Project Context* artifact. It is described in specs/0005-onboarding-agent.md and is the bridge between the onboarding flow and the ongoing agent work.

When a new user signs up, the onboarding agent scrapes the user's site, calls DataForSEO for a domain overview and a starter keyword list, and synthesizes a strategy in a single LLM call. The strategy is saved as a markdown document in the project, with a project_context row in D1 holding the latest version. The agent's output is the *source of truth* for the project. The MCP server exposes a get_project_context tool that returns the markdown. Any future agent session — including the seo-coach skill — starts by reading the project context.

This is the design decision that fixes the trust problem I described at the start of this chapter.

When you ask the seo-coach skill "what should I write about next?", the agent does not invent an answer from its training data. It reads the project context, reads the current rank tracker, reads the most recent keyword research, and reasons against the artifacts the project has actually saved. The agent's output is grounded in the user's own data, not in the model's priors. The agent can be wrong, but the agent cannot be confidently wrong about facts that are not in the source. The facts are in the source. The agent reasons about them.

This is the difference between an agent that *summarizes* and an agent that *works*. A summarizing agent reads data and writes prose. A working agent reads artifacts, mutates state, saves the mutation, and tells the user what it did. The OpenSEO design is the second one. The MCP tools are the verbs. The project context is the nouns. The agent is the grammar.

The onboarding flow, in detail

The onboarding flow itself is worth a paragraph, because the design has a couple of sharp moves.

The flow runs in five stages: profile, discover, read, signal, synthesize. The first three stages are mostly deterministic. The fourth stage is where the agent branches on site archetype: new site, established content site, local business, SaaS. The branching is narrative, not computational — the agent picks which DataForSEO calls to make based on what the site looks like, not the other way around. The fifth stage is the single LLM call.

The total cost is $0.10–$0.25 per signup. The DataForSEO spend is $0.04–$0.08 (two Labs live calls), the LLM spend is $0.05–$0.15, and the Cloudflare Browser Rendering cost is negligible. The project hard-caps the spend with a one-run-per-user policy and email verification before the DataForSEO call.

The cost cap matters. The product is gated by an email gate *before* the metered call, so drive-by abuse is not a billing risk. The team has thought about this. The cost cap is a design decision, not an afterthought.

The streaming is the part that makes the product feel alive. The agent narrates its work in real time. The user sees "Reading your homepage…" then "You look like a Notion alternative…" then "4 keywords ranking, 30 worth targeting…" then the strategy write-up. The streaming is not a trick. The streaming is a representation of the work the agent is doing, surfaced so the user can intervene if the agent is going off the rails.

What this is not

I want to name what the MCP server is *not*, because I think the design is sharper when you see what it refuses to do.

It is not a replacement for the dashboard. The dashboard exists. The dashboard is where the user goes to inspect the agent's work, to see the keyword clusters as a list, to look at the rank tracking chart, to read the backlinks. The dashboard is not where the work happens. The work happens in the agent loop. The dashboard is the debugger.

It is not a generic SEO skill library. The skills are tied to the OpenSEO MCP tools. You cannot run keyword-research against Semrush's data. The skills are coupled to the tools they call. This is a feature, not a bug. The skill is the workflow. The workflow assumes the tools. If you swap the tools, you swap the skill.

It is not a way to give the agent autonomy. The agent is narrated. The user sees the steps. The user can intervene. The user owns the project. The agent is an employee, not a contractor.

The new trust model

I have been thinking about why this design feels right to me, and I think it is because the trust model is different from the standard "AI agent" trust model.

The standard trust model is: the agent is smart, the agent might be wrong, trust the agent a little. The user reads the agent's output, decides whether to act on it, and accepts the risk. The agent's output is the surface the user inspects.

The OpenSEO trust model is: the agent is a tool, the agent's *side effects* are the surface the user inspects. The agent's output is incidental. The agent saves its work to a project the user owns. The user looks at the project, not the agent. The agent can be wrong about its prose. The agent cannot be wrong about the data it saved, because the data is the data, sitting in D1, ready to be queried.

This is the same trust model a code editor uses. The copilot can suggest code. The user reads the code, not the suggestion. The copilot is not trusted. The code is trusted. The code lives in a file the user controls.

The MCP server is the file system for SEO work. The skills are the agents. The agent does the work. The user inspects the work. The work is saved where the user can see it. This is the entire product, in one sentence.

I have not seen a competitor design this clearly. Most AI-SEO products put the chat in the foreground and the data in the background. OpenSEO puts the data in the foreground and the chat in the background. The chat is the verb. The data is the noun. The user owns the noun.

---

References:

---

The agent's output is incidental. The agent's side effects are the surface. The user owns the surface. The agent is a tool, not a contractor.