This server provides on-page SEO analysis via five MCP tools, requiring no API keys. It enables automated audits of public web pages, including structured data extraction, robots.txt and sitemap analysis, and link checking.
audit_page: Fetches a URL and returns title/meta description lengths, canonical tags, robots meta, Open Graph & Twitter card data, heading outlines, image alt coverage, word count, language, and hreflang attributes.
extract_schema: Extracts all JSON-LD blocks from a page, lists @type values, returns parsed objects, and reports any parse errors.
check_robots: Fetches and parses a site's robots.txt, showing user-agent groups, allow/disallow rules, declared sitemaps, and crawl-delay directives.
parse_sitemap: Parses a sitemap.xml or sitemap index, returning total URL count, a configurable sample of entries with lastmod dates, and nested sitemap references.
extract_links: Lists all page links categorized as internal/external/nofollow, and optionally HEAD-checks internal links (up to a configurable limit) to detect broken ones.
Enables retrieval of real-user Core Web Vitals from the Chrome UX Report API, including LCP, CLS, INP, FCP, and TTFB at the 75th percentile with Google's performance verdicts.
Click on "Install 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., "@mcp-seo-audit Audit example.com and give me a prioritized fix list."
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.
On-page SEO analysis as MCP tools.
An MCP server that exposes on-page SEO analysis — metas, structured data, robots.txt, sitemaps and links — as tools any MCP-compatible client can call. The six core tools need no API keys and no accounts: everything runs off plain public-page fetches. check_vitals optionally adds real-user Core Web Vitals with a free API key.
Tool | Returns |
| Title/meta lengths, canonical, robots meta, Open Graph & Twitter cards, headings outline, image alt coverage, word count, lang, hreflang |
| Every JSON-LD block parsed, |
| robots.txt user-agent groups, allow/disallow rules, declared sitemaps |
| URL counts, |
| Internal/external/nofollow split, optional broken-link check |
| Breadth-first crawl of internal links, auditing every page and aggregating findings by issue category |
| Real-user Core Web Vitals from the Chrome UX Report: LCP, CLS, INP (plus FCP and TTFB) at the 75th percentile with Google's good / needs improvement / poor verdicts — needs a free API key |
The server returns structured data and leaves the interpretation to the client. The same tools drive a quick audit, a competitor comparison, or a full crawl conversation.
Related MCP server: mcp-seo
Requires Node.js 20.18.1 or newer — cheerio pulls in undici 7, which needs the File global introduced in Node 20. On older versions the server fails to start.
No install step — register the server with any MCP client and npx fetches it on first run:
{
"mcpServers": {
"seo-audit": {
"command": "npx",
"args": ["mcp-seo-audit"]
}
}
}On Windows, wrap the command in cmd:
{
"mcpServers": {
"seo-audit": {
"command": "cmd",
"args": ["/c", "npx", "mcp-seo-audit"]
}
}
}To try it outside a client, npx mcp-seo-audit prints mcp-seo-audit ready and waits for a client on stdio.
For contributors, or to run an unreleased change:
git clone https://github.com/mk-techi/mcp-seo-audit
cd mcp-seo-audit
npm install
npm run devThen point the client at the local checkout instead of the published package:
{
"mcpServers": {
"seo-audit": {
"command": "npx",
"args": ["tsx", "/absolute/path/to/mcp-seo-audit/src/index.ts"]
}
}
}check_vitals queries Google's Chrome UX Report API — the Core Web Vitals real Chrome users experienced over the last 28 days, the same field data Google Search uses. It reads a key from the CRUX_API_KEY environment variable:
{
"mcpServers": {
"seo-audit": {
"command": "npx",
"args": ["mcp-seo-audit"],
"env": { "CRUX_API_KEY": "your-key" }
}
}
}The key is free and needs no billing account: create an API key in the Google Cloud console and enable the Chrome UX Report API for its project. Without the key, check_vitals explains how to get one and every other tool keeps working.
Once connected, the tools are available. Example prompts:
Audit example.com and give me a prioritized fix list.
Does this page have valid JSON-LD? Which types, and what's missing for rich results?
Compare the on-page SEO of my landing page against a competitor's.
Find broken internal links on the homepage.
How are my real-user Core Web Vitals on mobile, and which metric should I fix first?
npm run build # emits dist/
npm start # runs the compiled servercrawl_site - follow internal links up to N pages and aggregate issues
Schema validation against Google's rich results requirements
MIT
Fetch a URL and return structured on-page SEO data: title and meta description with lengths, canonical, robots meta, Open Graph and Twitter cards, headings outline, image alt coverage, word count, lang and hreflang.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it fetches a URL and returns data, but it does not mention potential side effects, error handling, redirects, or rate limits. The behavior is partially transparent but not deeply detailed.
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 but long, listing many output items. It is front-loaded with the main action and then enumerates details. While not overly verbose, it could be more structured (e.g., bullet points), so it earns a 4.
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?
With no output schema, the description must explain what the tool returns, and it does so by listing the specific SEO data fields. It lacks details on the response format or edge cases, but for a straightforward fetch-and-audit tool, it is reasonably complete.
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?
The schema covers the single 'url' parameter with type and format. The description mentions 'Fetch a URL' which effectively clarifies the parameter's purpose, but it adds no additional semantics beyond the schema. With only one parameter and 0% schema description coverage, it is minimally sufficient.
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 clearly states the tool fetches a URL and returns structured on-page SEO data, listing the specific elements. This distinguishes it from sibling tools like extract_links or check_robots, which focus on different aspects.
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 the tool is for on-page SEO auditing through its title and detailed list of SEO elements. It provides clear context but does not explicitly state when to use it over alternatives or mention exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a site's robots.txt and return user-agent groups with their rules, declared sitemaps and crawl-delay directives.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | Any URL on the site |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the output content (user-agent groups, sitemaps, crawl-delay) but does not disclose edge-case behavior such as missing robots.txt, HTTP errors, or redirect handling. It adds some context but not comprehensive behavioral transparency.
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, well-structured sentence that front-loads the action ('Fetch') and lists the return values concisely. Every word contributes meaning without redundancy.
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?
Given the tool's simplicity (one parameter, no output schema), the description sufficiently explains what it does and what it returns. It lacks details on potential errors or status codes, but for a direct robots.txt fetch-and-parse tool, the information is largely complete for an agent to use it correctly.
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?
The schema covers the single parameter siteUrl with a clear description ('Any URL on the site'), so schema coverage is 100%. The tool description does not add further parameter semantics, but this is unnecessary since the schema is fully self-explanatory.
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 clearly states the tool fetches a site's robots.txt and returns parsed data (user-agent groups, rules, sitemaps, crawl-delay), using a specific verb and resource. It unambiguously distinguishes itself from siblings like parse_sitemap and extract_links.
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 the tool is for inspecting robots.txt rules, and the sibling tool names provide contextual alternatives (e.g., parse_sitemap for sitemaps). However, it does not explicitly state when not to use it or mention alternatives, so it falls slightly short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a page's links split into internal and external with nofollow counts. Optionally HEAD-checks internal links to find broken ones.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| checkLimit | No | ||
| checkBroken | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior: splitting links into internal/external, counting nofollow, and optional HEAD-checks. However, it omits details like return format, pagination, or any rate limits or error behavior, leaving some transparency gaps.
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, well-structured sentence that front-loads the primary action and then adds the optional check behavior. Every word earns its place, with no fluff or redundancy.
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?
The tool is relatively simple, and the description covers its main behavior, but it lacks details about output format, the meaning of checkLimit, and any caveats around HEAD-checks. Given no output schema and no annotations, these gaps make the description adequate but not fully complete.
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?
The schema has 0% description coverage, so the description must compensate. It adds meaning to checkBroken via 'Optionally HEAD-checks internal links,' but checkLimit is left unexplained in both schema and description. The url parameter is self-evident, but the incomplete coverage for checkLimit prevents a higher score.
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 clearly states the tool's function: 'List a page's links split into internal and external with nofollow counts.' This is a specific verb and resource that distinguishes it from siblings like audit_page, extract_schema, check_robots, and parse_sitemap, which focus on other aspects.
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?
It clearly communicates that it can optionally HEAD-check internal links to find broken ones, giving a concrete use case. However, it does not explicitly contrast with sibling tools or state when not to use this tool, so it lacks full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract every JSON-LD block from a page, list the @type values found, and return the parsed objects along with any parse errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations absent, the description discloses that it extracts all JSON-LD blocks, lists @type values, and returns parsed objects with parse errors. This covers core behavior but does not address edge cases like missing JSON-LD or dynamic rendering.
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 front-loads the action ('Extract every JSON-LD block') and then lists the outputs. No unnecessary words.
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?
Given the simple single-parameter tool and lack of output schema, the description adequately lists the return contents (parsed objects and errors). It could be more specific about the response structure, but it is sufficient for basic understanding.
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?
The only parameter 'url' has no description in the schema, and the description only indirectly refers to it via 'from a page'. It does not explain expected URL format, accessibility requirements, or how the URL is used beyond the general context.
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?
Description states 'Extract every JSON-LD block from a page' with a clear verb and resource, and distinguishes itself from sibling tools like extract_links and parse_sitemap by focusing on JSON-LD structured data extraction.
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 the tool is for extracting JSON-LD structured data, but it does not explicitly state when to use it over alternative tools (e.g., extract_links for links). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a sitemap.xml or sitemap index and return the URL count, a sample of entries with lastmod, and any nested sitemaps.
| Name | Required | Description | Default |
|---|---|---|---|
| sampleSize | No | ||
| sitemapUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the burden, and it does cover the core behavior: fetching a sitemap and returning count, sample, and nested sitemaps. However, it omits details like error handling, response size limits, or whether it follows redirects, which are relevant for a networked fetch operation.
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, well-structured sentence that front-loads the action ('Fetch') and the key return elements. No redundant words or fluffy content.
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?
Given the lack of output schema, the description adequately summarizes the return values. It mentions URL count, sample entries with lastmod, and nested sitemaps. However, it could be more explicit about error conditions and the exact structure of the sample, but for a simple tool this is nearly complete.
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 0%, and the description does not mention the parameters. 'sitemapUrl' is only inferred from 'Fetch a sitemap.xml or sitemap index', while 'sampleSize' is entirely absent. The description adds no meaning beyond the parameter names.
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 uses specific verb 'Fetch' and resource 'sitemap.xml or sitemap index', clearly stating what it does. It distinguishes from siblings by focusing on sitemap-specific details (URL count, sample entries with lastmod, nested sitemaps), unlike extract_links or check_robots.
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?
Usage is implied rather than explicit: the description indicates when to use it (to parse a sitemap) but does not mention alternatives or exclusions. No reference to sibling tools like extract_links or check_robots, so the agent must infer context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0audit_pagecheck_robotsextract_linksextract_schemaparse_sitemapScored across 5 tools
Each tool targets a distinct aspect of SEO auditing: page content, schema, robots.txt, sitemaps, and links. There is no overlap in their purposes, making selection unambiguous.
All tool names follow a consistent verb_noun pattern: audit_page, extract_schema, check_robots, parse_sitemap, extract_links. The naming is predictable and follows a clear convention.
Five tools is well-scoped for an SEO audit server. Each tool covers a core aspect of SEO analysis without redundancy, and the count feels neither sparse nor bloated.
The tool set covers the essential components of a technical SEO audit: on-page elements, structured data, robots directives, sitemap discovery, and link analysis. There are no obvious gaps for a standard audit workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Free technical-SEO audit MCP: crawl a site, run checks, return an LLM-ready shareable report.
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
