Requests a URL and reports the final status code, redirect chain, response time, content type and size, and which security headers (HSTS, CSP, X-Frame-Options...) are present. 0.002 USDC per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL | |
| paymentProof | No | Payment proof: USDC tx hash on Polygon or Base (0x...) or Solana tx signature. Omit on the first call to receive the 402 payment instructions, pay, then call again with the proof. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations were provided, the description carries the full behavioral burden. It discloses key behavioral traits that are not evident from the schema, specifically the associated cost and the workflow required for the payment proof mechanism.
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?
The description is highly dense, but every clause serves a function: defining the operation, listing the returned metrics, and stating the billing cost. It avoids unnecessary jargon while remaining extremely packed with information.
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?
The description handles the unique and complex constraint of the tool—the required payment lifecycle—perfectly. By combining the detailed technical output description with the billing workflow, it leaves no ambiguity for the agent.
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?
With 100% schema coverage, the baseline score of 3 is appropriate. The description doesn't add semantic value to the specific data types of the parameters but provides necessary context on the lifecycle of the 'paymentProof' parameter.
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 is extremely specific, detailing that it requests a URL and reports a wide range of data, including status codes, redirect chains, response time, content type, and specific security headers like HSTS and CSP. This makes its function much clearer than general URL interaction tools.
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 description provides critical usage instructions regarding billing and prerequisites. It explicitly states that the tool incurs a cost ('0.002 USDC per call') and introduces a multi-step usage pattern involving the 'paymentProof' parameter.
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.