Lordevo Shop (x402 website checks)

Site report for agencies: client-ready audit + fix plan ($0.01/call)

site_report

Read-only

$0.01 per call (x402, USDC on Base; the call returns the payment terms: pay and retry with _meta["x402/payment"]). One call: a client-ready, evidence-backed website audit and remediation plan (SEO on up to 10 pages, passive security, links, email authentication, AI readiness). Every finding has evidence, observed/inferred basis, priority, effort, a concrete fix and how to verify it; plus a phased implementation plan, what needs human review, and an honest coverage section. JSON + Markdown + self-contained HTML, optional white-label branding. Passive, point-in-time; not a penetration test. Returns the finished site-report/1 or status "running" with result_url / delivery_id + key to poll (free tool site_report_status). Bad input is refused before payment; a report where every check fails is not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "authorization": "<authorization>"
    },
    "name": "site_report"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	Public http(s) website to assess
`scope`	No
`authorization`	Yes	You own the site or are authorised by its owner to assess it

Output Schema

Name	Required	Description	Default
`tier`	No
`status`	No
`target`	No
`product`	No
`practice`	No
`result_url`	No
`started_at`	No
`delivery_id`	No
`finished_at`	No
`report_html_url`	No
`report_markdown_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "anyOf": [
+    {
+      "required": [
+        "product",
+        "delivery_id",
+        "status",
+        "result_url"
+      ]
+    },
+    {
+      "properties": {
+        "accepts": {
+          "type": "array"
+        },
+        "error": {
+          "type": "string"
+        },
+        "resource": {
+          "type": "object"
+        },
+        "x402Version": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "x402Version",
+        "accepts"
+      ]
+    },
+    {
+      "properties": {
+        "charged": {
+          "type": "boolean"
+        },
+        "error": {
+          "type": "string"
+        },
+        "message": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "error"
+      ]
+    }
+  ],
+  "properties": {
+    "delivery_id": {
+      "type": "string"
+    },
+    "finished_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "practice": {
+      "type": "boolean"
+    },
+    "product": {
+      "type": "string"
+    },
+    "report_html_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "report_markdown_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "result_url": {
+      "type": "string"
+    },
+    "started_at": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "target": {},
+    "tier": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

AddedNov 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the paid flow ($0.01 x402 USDC on Base, retry with _meta["x402/payment"]), the async 'running' status with result_url/delivery_id plus a polling key, pre-payment input refusal, and the no-charge guarantee when every check fails. It also states the passive/non-intrusive boundary, which the readOnly/destructive hints alone do not convey.

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

Conciseness3/5

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

Every clause carries information, but it is delivered as one dense semicolon-chained block with pricing and payment mechanics front-loaded ahead of what the tool actually does. The content is not padded, yet the lack of structure makes it harder to scan than it needs to be.

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?

For a paid, async, nested-object tool, the description covers payment terms, polling, refusal/no-charge semantics, deliverable formats and the cognitive boundary of the audit. An output schema exists, so the description is right not to enumerate return fields beyond the 'running' status handling.

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 67%, and the description adds real meaning: the five assessable areas map to scope.areas, 'up to 10 pages' fixes max_pages, and 'JSON + Markdown + self-contained HTML, optional white-label branding' plus audience framing clarify scope.format and scope.brand. The authorization/attestation parameter is only covered by the schema, not elaborated in the description.

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 concrete verb and composite deliverable: a 'client-ready, evidence-backed website audit and remediation plan' covering SEO on up to 10 pages, passive security, links, email auth and AI readiness. The 'One call' framing distinguishes it from the granular siblings (seo_audit_lite, security_scan_lite, link_check) without needing to name them.

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?

Gives clear usage context: one consolidated call vs. per-check tools, with the explicit scope exclusion 'Passive, point-in-time; not a penetration test.' It also tells the agent what to do on an async outcome (poll free site_report_status) and that bad input is refused before payment. It never explicitly names which sibling to prefer for a single-area audit, so it stops short of top marks.

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

All Lordevo Shop (x402 website checks) 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.

Resources

Need Help?