x402-page-audit
Page Audit: Web page audit — SEO, accessibility, and performance.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Url to process | |
| input | No | Input to process |
Page Audit: Web page audit — SEO, accessibility, and performance.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Url to process | |
| input | No | Input to process |
Changes observed during successful MCP inspections.
Input schema / properties / urlAdded value: +{
+ "description": "Url to process",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It never says whether the page is fetched live, whether the call is read-only or has side effects, whether authentication/rate limits apply, or what the audit response contains. Only the audit dimensions (SEO, accessibility, performance) are hinted at.
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?
It is a single short, front-loaded sentence with no padding. The only waste is the redundant 'Page Audit:' prefix that merely restates the tool name before the actual content begins.
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 tool with no annotations, no output schema, and an ambiguous second parameter, the description is far too thin. An agent cannot determine the required input, the fetch behavior, or the shape of the returned audit, all of which the description would need to supply given the absent structured metadata.
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?
Both parameters carry only placeholder text ('Url to process', 'Input to process') that conveys nothing about format, which value takes priority, or what 'input' even means for an audit. The description adds no parameter meaning, and 'input' overlaps confusingly with 'url' while neither is marked required.
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?
The description names a specific verb ('audit') and resource ('Web page') and enumerates the audit dimensions (SEO, accessibility, performance), which is well beyond a tautology. However, it does nothing to separate this tool from close siblings such as x402-site-audit, x402-domain-audit, or x402-accessibility-check, so an agent cannot tell which of these to pick.
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?
There is no statement of when to use this tool, when not to, or which sibling to prefer for a full-site versus single-page sweep. The agent is left to infer selection from the name alone in a catalogue containing x402-site-audit, x402-domain-audit, and x402-accessibility-check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.