SEO MCP Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@SEO MCP ServerResearch competitors for 'sustainable fashion' and generate SEO page with FAQ schema."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SEO MCP Server
一个用于生成高质量 SEO 页面内容的 MCP Server,支持竞争对手研究和 Schema.org 结构化数据。
安装
npm install @euniii/seo-mcp-serverRelated MCP server: Locations MCP Server
功能说明
1. searchCompetitors 工具 - 竞争对手研究
搜索关键词的前 10 名竞争对手页面,获取他们的标题、摘要和链接。
输入: keyword(字符串,SEO 关键词)
输出: 包含前 10 名竞争对手的数组,每个对象包含 rank, title, snippet, url
2. generateSeoPage 工具 - 生成 SEO 页面
生成高质量 SEO 页面内容,包含完整的 Schema.org 结构化数据(FAQPage)。
输入: keyword(字符串,SEO 关键词)
输出: JSON 格式,包含:
title: 页面标题description: Meta 描述markdownContent: Markdown 格式的正文内容schemaData: Schema.org 结构化数据(JSON-LD 格式,FAQPage 类型)
配置
Serper.dev API Key (可选)
如果你想使用 searchCompetitors 工具:
复制
.env.example为.env访问 https://serper.dev/ 注册并获取 API Key(免费额度 2500 次/月)
在
.env文件中填入你的 API Key:
SERPER_API_KEY=your_serper_api_key_here使用示例
在 Trae/Claude 中,你可以这样使用:
帮我写一个关于 "React Hooks" 的 SEO 页面。
先调用 searchCompetitors 看看竞争对手都是怎么写的,
然后基于他们的内容生成一个更全面、覆盖维度更多的页面。Links
📁 GitHub: https://github.com/xxxeuniii/SEO_MCP
🔍 Serper.dev: https://serper.dev/
Available Tools
2 toolsgenerateSeoPageA
生成高质量 SEO 页面内容,包括 title、description、markdownContent 和 schemaData(Schema.org 结构化数据)
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | SEO 关键词 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It clearly indicates the tool generates content and lists the output components, which gives an agent a reasonable expectation of the result. However, it does not mention side effects, permissions, rate limits, or whether anything is persisted or published.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no filler or redundancy. It front-loads the action and resource, then lists the output fields efficiently, earning every word it uses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one required string parameter and no output schema, the description is largely complete: it names the input keyword and the four output content fields. It could be more complete by noting any assumptions about content language, length, or formatting, but it is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, keyword, is already documented as 'SEO 关键词'. The description adds that the keyword drives generation of a page but provides no extra syntax, formatting, or behavioral detail beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, '生成' (generate), a clear resource, 'SEO 页面内容' (SEO page content), and enumerates the concrete output fields: title, description, markdownContent, and schemaData. This clearly distinguishes it from the sibling searchCompetitors, which searches rather than generates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs SEO page content generated from a keyword, but it does not explicitly state when to use this tool over searchCompetitors or mention any exclusion conditions. The sibling context exists but is not leveraged in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchCompetitorsA
搜索关键词的前10名竞争对手页面,包括标题、摘要和链接
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | SEO 关键词 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool returns the top 10 results and includes title, snippet, and link, which is useful. It does not mention whether the operation is read-only, how results are ordered, or any limitations, but for a simple keyword search the disclosure is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly communicates the action, scope, and output fields with no filler. It is efficiently front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers input intent and output content reasonably well. It is slightly incomplete because it does not explain how it relates to generateSeoPage, but the tool's simple scope makes the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the keyword parameter. The description only restates that the keyword is the search term and adds no new detail such as format, length limits, or example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('search'), a specific resource ('top 10 competitor pages'), and the included fields ('title, snippet, and link'). This is clear and distinct from the sibling generateSeoPage, which implies generation rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use it when needing competitor search results for a keyword. However, there is no explicit guidance about when to prefer this over generateSeoPage or any when-not-to-use conditions, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v2.0.0- First observed
generateSeoPage - First observed
searchCompetitors
TDQS
Scored across 2 tools
The two tools have clearly non-overlapping purposes: one researches competitors for a keyword, the other generates SEO page content. There is no ambiguity about which tool to select.
Both tool names follow the same camelCase verb_noun pattern (searchCompetitors, generateSeoPage). The naming is consistent and predictable.
Two tools is on the thin side for a general SEO server, but each tool addresses a distinct step in a simple competitor-informed content workflow. It is borderline rather than well-scoped.
The pair supports a basic workflow: analyze competitors then generate a page. However, common SEO operations like keyword research, on-page audits, rank tracking, and content updates are absent, so coverage feels incomplete for the broad server name.
Maintenance
Related MCP Connectors
Turns SEO insight into page changes: keyword research, SERP and rank data, rewrites you approve.
AI-powered SEO and marketing: keyword research, SERP analysis, and content optimization tools.
SEO, competitor and AI-search data, plus blog management — draft, schedule and publish posts.
- VibeSEOOAuthdev.vibeseo
SEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides SEO automation with tools for keyword research, SERP analysis, and competitor analysis through Google Ads API integration, enabling AI assistants to access these capabilities via MCP.51-
- AlicenseNot gradedqualityNot gradedmaintenanceEnables WordPress content extraction, keyword research using Google autocomplete and Trends data, and generation of SEO-optimized content with quality metrics.-
- AlicenseCqualityDmaintenanceEnables SEO analysis by interacting with the Haloscan API, providing keyword research, site explorer, and SERP comparison tools.3373 npm3MIT
- FlicenseNot gradedqualityDmaintenanceEnables professional SEO/SEM research with geolocalized keyword discovery, competitor analysis, and SERP ranking insights using DataForSEO API.-