SEO Audit

Citation score (page)

score_page_citation

Read-onlyIdempotent

Cite-chance score for one page, 0 to 100. Use this when the user asks whether ChatGPT, Perplexity or Google AI Overviews are likely to cite a page, or how to fix that. Pass exactly one of url, html, text, or sample. Returns the score and a fix list ordered by the biggest point gain. The checks cover an answer in the opening, question headings, an FAQ block, structured data, lists and tables, heading order, short sentences, a number with a source, a recent date, and an author line. Pasted html and text are scored as given and are not fetched. A url is one public page, with robots.txt respected. It does not call an AI engine and it does not promise a citation. Use compare_citations when the user has the pages an AI answer cited. Do not use it for private or local addresses, rankings, or traffic.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	One public page address. A bare domain means https. Do not pass this together with html or text.
`html`	No	Pasted HTML of one page. Scored as given. Nothing is fetched.
`text`	No	Pasted plain text or Markdown. Scored as given. Nothing is fetched.
`sample`	No	Score a built-in example page. Use this when the caller has no page yet.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	No
`fixes`	Yes	Fixes that still raise the score, largest gain first.
`notes`	Yes
`score`	Yes	0 to 100. The sum of points earned.
`checks`	Yes
`notice`	Yes
`source`	Yes
`finalUrl`	No
`reachable`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 10, 2026

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "url"
+    ]
+  },
+  {
+    "required": [
+      "html"
+    ]
+  },
+  {
+    "required": [
+      "text"
+    ]
+  },
+  {
+    "required": [
+      "sample"
+    ]
+  }
+]

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

AddedOct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses that pasted html/text are scored as-is with no fetch, that a url is limited to one public page and honours robots.txt, that no AI engine is called, and that no citation is promised. This is exactly the kind of scope/expectation context the safety annotations cannot convey.

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

Conciseness4/5

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

Front-loaded with purpose, then inputs, then output, then limitations, then routing. Every sentence carries information, though the middle enumeration of ten on-page checks is a long list that could be tightened.

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?

Even with an output schema present, the description summarises the return ('score and a fix list ordered by the biggest point gain') and bounds the input modes, fetch behaviour, and exclusions. Nothing needed 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.

Parameters4/5

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

The schema already documents all four parameters at 100% coverage, including the mutual exclusion in the anyOf and property notes, so the baseline is 3. The description's consolidated rule 'Pass exactly one of url, html, text, or sample' plus the input-mode framing (fetch vs. paste vs. built-in example) adds modest upfront clarity over the machine-readable constraint, but largely restates the schema.

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 opening sentence gives a concrete verb+resource with a bounded output range: 'Cite-chance score for one page, 0 to 100.' It also names the sibling it is not (compare_citations), so an agent can route correctly without opening either schema.

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?

Explicit triggering condition ('when the user asks whether ChatGPT, Perplexity or Google AI Overviews are likely to cite a page, or how to fix that'), a named alternative with its own condition ('Use compare_citations when the user has the pages an AI answer cited'), and exclusions ('Do not use it for private or local addresses, rankings, or traffic').

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

All SEO Audit tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.