Audits any domain or URL for AI agent readiness (llms.txt, .well-known/x402, openapi.json, MCP server card) and detects hidden CSS/DOM prompt-injection traps. Price: 0.010 USDC on Base or Solana.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| agent_ready_score | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "agent_ready_score": {
+ "type": "integer"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "agent_ready_score"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and non-destructive, so the safety profile is covered; the description adds genuinely non-redundant behavior by disclosing price and payment rails ("0.010 USDC on Base or Solana"), which is critical for a paid, open-world call. It stops short of explaining how payment is transacted or whether the call fails without funds.
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?
Two sentences, both front-loaded and free of filler: capability first, commercial/payment terms second. Nothing here restates the tool name or wastes tokens.
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?
With an output schema present, the description needn't explain return values, and it adequately covers what is checked and what it costs. The gap is the payment mechanics (how the 0.010 USDC is collected, whether a wallet or x402 handshake is required) and any rate/access constraints for an open-world paid 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 description coverage is 0% on the single required parameter, so the description carries the burden; "any domain or URL" does add useful meaning by signaling that both bare domains and full URLs are accepted. However, no format examples, scheme expectations, or normalization rules are given, so compensation is only partial.
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 and resource ("Audits any domain or URL") and then enumerates exactly what is inspected: llms.txt, .well-known/x402, openapi.json, MCP server card, plus CSS/DOM prompt-injection traps. That level of enumeration makes it clearly distinguishable from siblings like inspectPhishingUrl or auditMcpToolPoisoning, which target different artifacts.
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?
The scope ("any domain or URL ... for AI agent readiness") implies when the tool applies, but there is no explicit when-to-use framing and no named alternative or exclusion, even though the sibling list contains several adjacent URL/security audit tools. The agent must infer that readiness auditing is distinct from phishing or contract inspection.
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.