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., "@@operstack/mcp audit example.com and explain why ChatGPT recommends competitors"
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.
Let Claude, Cursor or any MCP client measure a site the way a search engine and an AI actually read it.
Ask your assistant "why does ChatGPT recommend my competitor and not me?" and it can now go and look: read the site, score six areas, follow the map the site offers to machines, and tell you what is actually missing. Free public signals only. No account, no API key, nothing stored.
In Claude Desktop, add this to claude_desktop_config.json:
{
"mcpServers": {
"operstack": {
"command": "npx",
"args": ["-y", "@operstack/mcp"]
}
}
}In Cursor, add the same block to .cursor/mcp.json in your project, or to ~/.cursor/mcp.json for every project.
Node 20 or newer. Nothing else to install.
Related MCP server: librecrawl-technical-seo-audit-mcp
audit_site reads a public site and scores six areas out of ten: technical SEO, content and structure, AEO (whether an answer engine can quote it), GEO (whether AI systems can identify and use it), off-page trust, and conversion. Returns every failing and borderline check with what was actually found on the pages, so the assistant can explain rather than guess.
check_llms_txt reads the site's /llms.txt, checks it against the format, and follows its links to see whether each one still leads to a page, a redirect or nothing. This file rots silently, because no human ever opens it.
compare_sites runs the same measurement on two to four sites and returns them side by side. Useful when the question is not "am I bad" but "am I worse than them, and where".
run_gates runs the sixteen OperStack content gates on a folder of Markdown or MDX on your own machine: cut titles, copied paragraphs, hollow sections, dead links, redirect chains, a stale agent index, figures with no source, and the agent surface. Files are read locally and sent nowhere.
It will not invent a number. Where something was not measured it says so and why. It will not score a site on data that costs money: every figure comes from what any stranger can read on the site for nothing, which means you can reproduce it yourself. It will not report on a site that did not answer: a typo in the address gets a refusal, not a page of findings about nothing.
It keeps nothing. The address you check is used for the request and forgotten. There is no telemetry, no cache and no account.
Every measurement here runs through @operstack/audit, the same package behind the paid OperStack reports. A free tool that disagrees with the paid one is the fastest way to lose the reader, so they are the same code.
Sixteen content gates, free, MIT
Astro starter that already passes them, free, MIT
MIT.
Read a public site and score six areas out of ten: technical SEO, content and structure, AEO (whether an answer engine can quote it), GEO (whether AI systems can identify and use it), off-page trust, and conversion. Returns every failing and borderline check with what was actually found on the pages. Free public signals only: no account, no paid tool, nothing stored. Use it when someone asks why a site is not being cited, why AI assistants recommend competitors, or what to fix first.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The site to read, for example example.com or https://example.com/ | |
| lang | No | Language of the check names and findings. Default en. | |
| pages | No | How many pages to sample from the sitemap. Default 12; more pages take longer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the read-only nature of the operation, that only free public signals are used, that no account is needed, and that nothing is stored. It omits runtime/rate behavior and any failure modes, which keeps it below 5.
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?
Three dense sentences, front-loaded with the verb and the scoring scope, followed by output content and then usage triggers. Every sentence earns its place; the parenthetical explanations of AEO/GEO add clarity without much bloat.
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?
There is no output schema, so the description must explain returns, and it does: six scores out of ten plus every failing and borderline check with observed findings. Combined with the schema documenting all three parameters, an agent has nearly everything needed to call 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?
Schema coverage is 100%, so url, lang, and pages are all documented in the schema, making 3 the baseline. The description adds only the general notion of reading a public site and samples from the sitemap, no extra per-parameter meaning.
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?
States a concrete verb+resource (read a public site and score it) and enumerates the six scoring areas, which is far more specific than a tautology. It does not name or differentiate against siblings like compare_sites or check_llms_txt, so it stops short of the 5 bar for explicit sibling distinction.
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?
Gives three concrete trigger scenarios ('why a site is not being cited', 'why AI assistants recommend competitors', 'what to fix first'), which is clear context for invocation. It offers no when-not conditions and does not route to the alternative siblings, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a site's /llms.txt, check it against the format (one H1 naming the site, a summary, sections of links) and follow its links to see whether each still leads to a page, a redirect or nothing. This file rots silently because no human ever opens it. Use it when someone asks whether their llms.txt is correct, why an assistant quotes the wrong pages, or before publishing a new one.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The site to check, for example example.com | |
| maxLinks | No | How many links to follow. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that links are followed and classified as page, redirect, or nothing, and explains the failure mode ('rots silently'). It doesn't state rate limits, auth needs, or how results are returned, which keeps it from a 5.
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?
Three sentences front-loaded with the action, then the rationale, then the usage triggers. Every sentence earns its place with no filler.
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?
Covers purpose, behavior, and usage for a 2-parameter tool with full schema coverage and no output schema. It could add a note on how findings are surfaced given no output schema, but otherwise nothing an agent needs to invoke it correctly is missing.
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 coverage is 100%, so both 'url' and 'maxLinks' are already documented with examples and bounds in the schema. The description adds no extra syntax, format, or default details beyond what the schema provides. Baseline 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?
States a specific verb (read/check/follow) on a specific resource (/llms.txt) and enumerates what is verified: H1, summary, sections of links, and link liveness. This distinguishes it from siblings like audit_site or compare_sites, which are broader checks.
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?
Explicitly names three triggering scenarios: validating a site's llms.txt, diagnosing wrong-page quotes by assistants, and pre-publication checks. It also conveys the implicit 'when not' by framing this as the targeted llms.txt-specific tool versus general site audits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the same six-area measurement on two to four public sites and return them side by side. Use it when someone asks why a competitor is being quoted instead of them, or wants to know where the gap actually is rather than guessing. Free public signals only.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| urls | Yes | The sites to compare. The first one is treated as yours. | |
| pages | No | Pages to sample per site. Default 8. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully constrains scope ('public sites', 'free public signals only') and hints at the shared measurement basis, which is helpful context, but discloses nothing about authorization needs, rate limits, latency, or failure modes for non-public URLs.
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?
Three short sentences, front-loaded with the core action before the usage scenario. The middle sentence is slightly conversational but each clause still carries routing value, so little is wasted.
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?
There is no output schema and no annotations, so the description is the only source of behavior. It says results come back 'side by side' but never enumerates the six measurement areas an agent would need to interpret the output, leaving the return shape underspecified for a comparison tool.
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 coverage is 67%, with urls and pages already documented in-schema (including the 'first one is yours' ordering convention). The description reinforces the two-to-four site bound, matching the schema's min/max, but says nothing about the undocumented lang enum or what 'six areas' comprises. Adequate but not compensating for the gap.
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?
States a concrete verb and resource: it runs 'the same six-area measurement on two to four public sites' and returns results 'side by side'. This makes the multi-site comparative nature clear and implicitly separates it from the single-site audit_site sibling, though it never names that sibling explicitly.
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?
Gives concrete triggering scenarios ('why a competitor is being quoted instead of them', 'where the gap actually is'), which tells the agent when this tool applies. It stops short of naming alternatives like audit_site or run_gates, so the routing decision for a single-site case is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the sixteen quality gates on a folder of Markdown or MDX content on this machine: cut titles, copied paragraphs, hollow sections, dead links, redirect chains, a stale agent index, figures with no source, and the agent surface. Returns the report. Use it before publishing, or when asked what is wrong with a content corpus. It needs a local path, not a URL, and it reads files without sending them anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| only | No | Comma-separated gate numbers to run, for example 1,4,16. Default all. | |
| path | Yes | Absolute path to the project folder that holds the content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose key traits: it operates on a local folder rather than a URL, and it 'reads files without sending them anywhere,' which establishes a read-only, no-network profile. It does not state runtime, whether anything on disk is modified, or how the report is delivered.
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?
Three tight sentences front-loaded with purpose, then scope of gates, then usage and constraints. Every clause carries information; nothing is redundant filler.
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 two-parameter, read-oriented tool with no output schema and no annotations, the description covers what it does, what it checks, when to use it, and the local-only constraint. It stops short of describing report shape or how many/named gates map to the `only` argument.
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 coverage is already 100%, so the baseline is 3; the description adds real meaning by constraining the path to a 'local path, not a URL,' which is a distinction the schema alone does not make. The `only` gate-selection parameter is left entirely to the schema.
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?
Names a specific verb (run) and resource (sixteen quality gates on a folder of Markdown/MDX content) and enumerates the exact gate categories checked, so the agent knows what work happens. The 'on this machine / local path, not a URL' framing implicitly separates it from the remote-oriented siblings compare_sites and audit_site.
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?
Gives two concrete triggering conditions: 'Use it before publishing, or when asked what is wrong with a content corpus.' No when-not guidance and no explicit routing to siblings such as audit_site or check_llms_txt, but the usage context is clear.
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_sitecheck_llms_txtcompare_sitesrun_gatesScored across 4 tools
Each tool has a fairly distinct purpose: single-site audit, multi-site comparison, llms.txt validation, and local content gates. However, compare_sites is essentially a multi-site extension of audit_site, and check_llms_txt overlaps with the AEO/GEO portion of audit_site, so an agent could occasionally waver between them despite the clarifying descriptions.
All four tools follow a clean verb_noun snake_case pattern: compare_sites, audit_site, check_llms_txt, run_gates. The convention is predictable throughout with no style mixing.
Four tools is a reasonable, well-scoped count for a site-measurement server, and each earns its place. It leans slightly thin, since there is no tool for remediation or reporting beyond the core diagnostics.
The surface covers the core diagnostic lifecycle: single-site audit, competitor comparison, a specific llms.txt check, and local corpus gates. Minor gaps remain—no historical tracking, export/reporting, or standalone robots/schema checks—but agents can work around these for the stated purpose.
Free technical-SEO audit MCP: crawl a site, run checks, return an LLM-ready shareable report.
Check website AI-readiness: Schema.org, llms.txt, E-E-A-T, robots.txt. Works in Cursor & Claude.
Run SEO + AI-visibility (GEO) audits from Claude, Cursor & other AI clients.
Audit a page for search and AI answer engines; generate robots.txt, sitemap, head, llms.txt.
