Skip to main content
Glama
Mehmoodqureshi

seo-mcp

by Mehmoodqureshi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

seo-mcp

CI npm license

An SEO MCP server — a stdio Model Context Protocol server that gives an AI host a set of SEO tools. The MVP is 100% free and keyless: on-page/technical audits, robots.txt, sitemaps, structured data, broken-link checks, and keyword ideas.

Built on the same proven scaffold as chrome-mcp: SDK Server → StdioServerTransport, a flat tool registry, and a never-throw dispatch firewall.

Tools (all free, no API key)

Tool

What it does

audit_page

Full on-page audit: title, meta description, canonical, robots, viewport, OG/Twitter, heading outline, word count, image alt coverage, link counts, structured-data presence → issues + 0–100 score. Pass pagespeed: true to also attach PageSpeed metrics

check_robots

Fetch & parse /robots.txt — UA groups, allow/disallow, declared sitemaps

check_sitemap

Discover & summarize a sitemap (index vs urlset, URL count, sample)

extract_schema

Pull JSON-LD structured data and list schema.org @types (+ microdata, parse errors)

find_broken_links

HEAD-check links on a page; report 4xx/5xx/unreachable

keyword_ideas

Related queries for a seed term via Google Suggest (no volume)

pagespeed

Google PageSpeed Insights (Lighthouse): perf score, lab Core Web Vitals + real-user CrUX field data + top opportunities. Keyless (rate-limited); set PAGESPEED_API_KEY to raise the quota

Related MCP server: gkb-seo-mcp-server

Use it as an MCP server

Requires Node 20+. There is nothing to clone, build, or configure — add this to your MCP host config (e.g. a project .mcp.json) and restart the host:

{
  "mcpServers": {
    "seo-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@mehmoodqureshi/seo-mcp"]
    }
  }
}

Or with Claude Code: claude mcp add seo-mcp -- npx -y @mehmoodqureshi/seo-mcp

Or, after npm install -g @mehmoodqureshi/seo-mcp, set "command": "seo-mcp" with no args.

Windows

WSL2 is not required — native Windows works. One config change is, though: on Windows npx is npx.cmd, a batch shim, and MCP hosts spawn the server without a shell, which cannot execute a .cmd. So "command": "npx" fails to start. Wrap it in cmd /c:

{
  "mcpServers": {
    "seo-mcp": {
      "type": "stdio",
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@mehmoodqureshi/seo-mcp"]
    }
  }
}

Or: claude mcp add seo-mcp -- cmd /c npx -y @mehmoodqureshi/seo-mcp

Develop

From a source checkout:

npm install
npm run build      # → dist/src/cli.js
npm test

Then point your host at the local build with "command": "node", "args": ["<abs-path>/dist/src/cli.js"].

Then ask things like "audit https://example.com for SEO" or "what does example.com's robots.txt block?".

Quick smoke test (no MCP host needed)

node -e "require('./dist/src/seo/audit').auditPage('https://example.com').then(r=>console.log(JSON.stringify(r,null,2)))"

Develop

npm run typecheck   # tsc --noEmit
npm run build       # → dist/
npm test            # node:test suite (no network — fetch is stubbed)

CI (.github/workflows/ci.yml) runs typecheck → build → test on Node 20/22. Node 20+ is required (cheerio 1.x depends on undici, which needs the global File added in Node 20).

Performance & output size

  • Request caching — identical GETs are de-duplicated by a short-TTL cache with in-flight coalescing, so a audit_page → export_audit_pdf pair (or a sitemap/robots.txt referenced during a crawl) hits the network once. Tune with SEO_MCP_CACHE_TTL_MS (milliseconds, default 15000); set 0 to disable.

  • Compact audit_site — by default the site audit returns a slim, worst-first per-page table (score + issue counts) plus the aggregates, to keep the response small inside an MCP host's context. Pass detail: true for the full per-page breakdown, or use export_site_pdf for a formatted report.

PageSpeed (optional key)

The pagespeed tool works keyless but Google rate-limits anonymous requests. To raise the quota, grab a free PageSpeed Insights API key and set it in your MCP host config:

{
  "mcpServers": {
    "seo-mcp": {
      "type": "stdio",
      "command": "node",
      "args": ["/Users/mehmoodqureshi/Work/seo-mcp/dist/src/cli.js"],
      "env": { "PAGESPEED_API_KEY": "your-key-here" }
    }
  }
}

Roadmap (needs a key — not in the free MVP)

  • serp_rank — real SERP position checks (drive a browser, or a paid SERP API)

  • domain_authority — OpenPageRank (free key) for an authority score

  • backlinks — real backlink profiles (paid: Ahrefs / SEMrush / DataForSEO)

License

MIT

Available Tools

8 tools
audit_pageA

Full on-page SEO audit of a URL: title, meta description, canonical, robots, viewport, Open Graph/Twitter, heading outline, word count, image alt coverage, internal/external link counts, structured-data presence, plus a list of issues and a 0–100 score. Free, no API key. Set pagespeed=true to also attach PageSpeed Insights performance metrics. After presenting the results, ASK THE USER whether they want a professionally formatted PDF report; if they say yes, call export_audit_pdf with the same url (and same pagespeed/strategy).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPage URL (https:// optional)
pagespeedNoAlso run PageSpeed Insights and attach performance metrics (default false)
strategyNoPageSpeed strategy when pagespeed=true: "mobile" (default) or "desktop"

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description fully bears the burden. It discloses everything the tool does, including optional pagespeed integration, and notes that PDF generation requires a follow-up call. No destructive actions or contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is succinct (about 6 sentences), front-loaded with the main purpose, and includes only essential information. No extraneous words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (many checks) and no output schema, the description thoroughly enumerates all output items (title, meta, issues, score, etc.) and provides next-step instructions. It is complete for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all three parameters described. The description adds extra context: url accepts 'https:// optional', pagespeed defaults to false, strategy defaults to mobile. It explains the interplay between pagespeed and strategy parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a 'Full on-page SEO audit of a URL' and lists specific elements (title, meta description, canonical, etc.), distinguishing it from siblings like check_robots or check_sitemap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states it is 'Free, no API key', advises when to set pagespeed=true, and instructs to ask the user for a PDF report then call export_audit_pdf with specific parameters. This provides excellent guidance on when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_robotsA

Fetch and parse a site's /robots.txt — user-agent groups, allow/disallow rules, and declared sitemaps.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAny URL on the site

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior. It indicates a network fetch but does not mention error handling (e.g., missing robots.txt), rate limits, or caching. Adequate but could be improved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence that is front-loaded with the verb and resource, no wasted words, efficiently conveys the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the main functionality and outputs. However, it lacks details on edge cases like missing robots.txt, which would be helpful for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'url' is described in the schema as 'Any URL on the site'. The tool description reinforces this by stating 'Fetch and parse a site's /robots.txt', but adds no additional semantic nuance. Schema coverage is 100%, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Fetch and parse') and the resource ('a site's /robots.txt'), and specifies the outputs ('user-agent groups, allow/disallow rules, and declared sitemaps'). This distinguishes it from sibling tools like check_sitemap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for robots.txt checking but does not explicitly state when to use this tool versus alternatives like check_sitemap. No guidance on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_sitemapA

Discover and summarize a sitemap (via /sitemap.xml or robots.txt): index vs urlset, URL count, and a sample of URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAny URL on the site

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains what the tool does but lacks details on behavioral traits such as read-only nature, rate limits, or permission requirements. Adequate for a simple read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action and summarizes outputs with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is mostly complete. It covers the action and key outputs, though it could mention whether the full sitemap content or only a summary is returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the single parameter 'url' described as 'Any URL on the site'. The description adds no extra semantic meaning beyond the schema, meeting baseline expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool discovers and summarizes a sitemap, listing specific outputs (index vs urlset, URL count, sample URLs). This clearly distinguishes it from sibling tools like check_robots and audit_page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for sitemap overview but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

export_audit_pdfA

Generate a professionally laid-out PDF report of an on-page SEO audit (score badge, summary cards, severity-colored issue list, metadata, content/structure, social tags, and optional PageSpeed metrics). Re-runs the audit for the URL and writes a .pdf to disk, returning the file path. Use this after audit_page when the user asks for a PDF report.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPage URL to audit and export (https:// optional)
pathNoOutput file path (default: ./seo-audit-<host>-<date>.pdf in the current directory). ".pdf" is appended if missing.
pagespeedNoAlso run PageSpeed Insights and include performance metrics in the report (default false)
strategyNoPageSpeed strategy when pagespeed=true: "mobile" (default) or "desktop"

TDQS

A4.3/5.0
Behavior4/5

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 that the tool re-runs the audit, writes a .pdf to disk, and returns the file path. It also notes the optional PageSpeed metrics. No contradictions observed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: first explains what the tool produces, second explains the process and return value, third gives usage guidance. Every sentence adds unique value, and there is no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters (1 required), no output schema, and no annotations, the description covers all necessary aspects: purpose, process, return value, and usage context. It is sufficiently complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds context about the tool's behavior (re-running audit, writing to disk) but does not provide additional meaning for each parameter beyond what the schema already describes. The parameters are adequately documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs and nouns: 'Generate a professionally laid-out PDF report of an on-page SEO audit' and enumerates report contents. It also distinguishes from siblings by noting it is used after audit_page and can include PageSpeed metrics, which other tools do not provide as a PDF.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Use this after audit_page when the user asks for a PDF report.' This provides clear context for when to invoke this tool, though it does not explicitly list when not to use it or mention alternative tools beyond audit_page.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

extract_schemaA

Extract JSON-LD structured data from a page and list the schema.org @types found (plus any microdata itemtypes and JSON-LD parse errors).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPage URL

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must carry the burden. It discloses that the tool extracts structured data and reports errors, implying a read-only operation. However, it does not explicitly state non-destructiveness, authentication needs, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the core action and outputs. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no output schema, and missing annotations, the description provides sufficient context: the tool extracts and lists specific structured data types and errors. Slightly less informative for a read-heavy tool, but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description adds no new information about the 'url' parameter beyond the schema's 'Page URL' description. No format constraints or examples are given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'extract' and the resource 'JSON-LD structured data from a page', and specifies what it returns (schema.org @types, microdata itemtypes, parse errors). It distinguishes from sibling tools like audit_page and check_robots by focusing on 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates usage for extracting structured data, but lacks explicit guidance on when to use this tool versus alternatives (e.g., audit_page). No exclusions or context are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keyword_ideasA

Get related keyword/query ideas for a seed term via Google Suggest (free; related queries only, no search volume).

ParametersJSON Schema
NameRequiredDescriptionDefault
seedYesSeed keyword or phrase
langNoLanguage code, e.g. "en" (default)

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description describes the tool as free, using Google Suggest, and returning only related queries (no volume). With no annotations, this provides basic behavioral context, but it lacks details on rate limits, authentication requirements, or potential errors, which would be helpful for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that packs all necessary information (purpose, source, limitations) without any redundancy or filler. It is well front-loaded and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description provides sufficient context: source, free nature, and data limitation. It could mention response format or even a note on rate limiting to be fully complete, but it covers essentials well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all parameters with descriptions (100% coverage). The description adds minimal extra meaning beyond what the schema provides, only reiterating the seed term. With full schema coverage, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves 'related keyword/query ideas for a seed term' via Google Suggest. It uses a specific verb ('Get') and resource, and the context of 'free; related queries only, no search volume' distinguishes it from sibling tools like audit_page 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it is free and returns only related queries without search volume, giving clear context for when to use. However, it does not explicitly state when not to use it or provide alternative tools for volume data, missing a small opportunity for guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pagespeedA

Run Google PageSpeed Insights (Lighthouse): performance score (0–100), lab Core Web Vitals (LCP, CLS, TBT, FCP, Speed Index, TTI), real-user CrUX field data when available (LCP, CLS, INP, FCP, TTFB), and the top improvement opportunities. Works keyless (rate-limited); set PAGESPEED_API_KEY to raise the quota.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPage URL
strategyNo"mobile" (default) or "desktop"

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations present, but the description covers key behavioral aspects: read-only operation, rate limits, and that results include lab and field data. Transparent about return data structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: one sentence detailing outputs, one sentence on quotas. No fluff, front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description enumerates key return values: performance score, lab CrUX, field data, opportunities. Adequately complete for a simple API tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The description adds no extra semantic meaning beyond restating defaults and one usage note. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it runs PageSpeed Insights and lists specific outputs (score, Core Web Vitals, field data, opportunities). Does not explicitly differentiate from siblings like 'audit_page' but the focus on performance makes it distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions keyless usage with rate limits and optional API key for higher quota, providing usage context. Does not explain when to use this tool versus similar siblings.

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.

  1. 8 tool updatesv0.1.0
    • First observedaudit_page
    • First observedcheck_robots
    • First observedcheck_sitemap
    • First observedexport_audit_pdf
    • First observedextract_schema
    • First observedfind_broken_links
    • First observedkeyword_ideas
    • First observedpagespeed
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

Each tool targets a distinct SEO task (audit, robots, sitemap, schema, broken links, keywords, performance). However, there is some overlap because `audit_page` can optionally include PageSpeed results, making the separate `pagespeed` tool redundant and causing slight ambiguity in which to use for performance analysis.

Naming Consistency4/5

The naming convention is predominantly verb_noun in snake_case (e.g., audit_page, check_robots). Exceptions are `keyword_ideas` (noun_noun) and `pagespeed` (single word), which break the pattern but are still comprehensible.

Tool Count5/5

With 8 tools, the server covers common SEO diagnostic tasks without being bloated. Each tool serves a clear purpose, and the number fits the domain well.

Completeness4/5

The set covers essential on-page SEO areas: audit, robots.txt, sitemap, structured data, broken links, keywords, and performance. Missing advanced features like backlink analysis or content suggestions, but for a free MCP it is reasonably complete. The workflow dependency between `audit_page` and `export_audit_pdf` is well documented.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-seo-auditor

    arturseo-geo
    A
    license
    A
    quality
    D
    maintenance
    MCP server for on-page SEO auditing and JSON-LD schema validation, providing tools for full SEO audit, schema validation, heading hierarchy, and image audit without requiring API keys.
    4
    1
    MIT

  • gkb-seo-mcp-server

    nuppawat6
    F
    license
    A
    quality
    C
    maintenance
    An MCP server providing 20 SEO tools including coverage reports, supporting both stdio and HTTP modes for data-driven SEO analysis.
    20
    -

  • SEO MCP

    pradilla
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides SEO analysis tools including backlink analysis, keyword research, and traffic estimation using Ahrefs data, with CAPTCHA solving and caching.
    MIT

  • mcp-seo-tools

    rog0x
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that provides a suite of SEO analysis tools for auditing meta tags, headings, links, keyword density, page speed, and sitemaps without requiring external API keys.
    6
    25 npm
    1
    MIT