@true402.dev/mcp-server

seo_audit

Audit web pages for SEO + GEO (generative-engine optimization). POST { url, mode? } for a single page, or `{ urls: [...], mode?

Instructions

Audit web pages for SEO + GEO (generative-engine optimization). POST { url, mode? } for a single page, or { urls: [...], mode? } to audit several in one call — priced per page ($0.02/page, up to 10 pages per request on this deployment). An unpaid request returns 402 with payment requirements. After payment, a single url returns a flat report (per-category scores + issues); urls returns { count, succeeded, pages: [...] }. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.) Price: $0.02–$0.2 USD/page (DYNAMIC — can exceed a fixed MAX_PAYMENT_USDC ceiling; raise it if a call is refused).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "seo_audit"
  }
}

Input Schema

Name	Required	Description
`url`	No	A single page URL to audit (http/https). Charged as 1 page.
`mode`	No	Which analysis to run (default both)
`urls`	No	Several page URLs to audit in one call (up to 20; this deployment prices at most 10 per request). Charged per page.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.3.0Oct 22, 2026

changedInput schema / properties / url / description

Previous value: -"The page URL to audit (http/https)"New value: +"A single page URL to audit (http/https). Charged as 1 page."

addedInput schema / properties / urls

Added value: +{
+  "description": "Several page URLs to audit in one call (up to 20; this deployment prices at most 10 per request). Charged per page.",
+  "items": {},
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "url"
-]
```

First observedv0.7.1Jun 20, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the x402 payment model (USDC on Base, funded wallet required), the 402 response for unpaid calls, per-page pricing, the 10-page deployment cap, and the distinct return shapes for single vs batch. It even warns that dynamic pricing can exceed a fixed MAX_PAYMENT_USDC ceiling and must be raised — exactly the operational context an agent needs.

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 the purpose and call shapes, and nearly every clause carries actionable information for a paid tool. Minor deduction for stating pricing twice with slightly different framings ($0.02/page then $0.02–$0.2 USD/page DYNAMIC), which creates a small internal tension in an otherwise tight paragraph.

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?

There is no output schema, but the description compensates by describing both return shapes (flat report vs `{ count, succeeded, pages }`). Combined with the payment mechanics, batching limits, and per-page pricing, an agent has everything needed to invoke this correctly and anticipate the failure mode.

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?

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning beyond the schema: it clarifies the `mode` default in prose and, critically, resolves a conflict by noting that although the schema allows up to 20 URLs, this deployment prices at most 10 per request. That is a genuine semantic contribution, though `mode` enum values are not elaborated.

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?

States a specific verb and resource — audit web pages for SEO + GEO — and immediately distinguishes the two call shapes (single `url` vs `urls` batch). The scope is narrow and clearly different from nearby sibling tools like `serp`, `backlinks`, or `web_extract`.

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 clearly signals when to use the batch form versus the single form, which is real guidance. However it never says when to reach for this tool instead of siblings such as `serp`, `backlinks`, or `keyword_volume`, nor does it give exclusions (e.g. robots-blocked or non-HTML URLs).

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