ScorpTech x402 API

Link Check

link_check

Read-onlyIdempotent

Find broken links on a public web page (or in supplied HTML, e.g. a draft before publishing): fetches the page (SSRF-safe), extracts links (optionally images / scripts / stylesheets too), then checks up to 50 of them in parallel with HEAD (falling back to GET), every target re-validated against private / internal addresses and pinned to its checked IP. Reports status, category (ok / redirect / broken / error / blocked), redirect location, response time and anchor text, broken first. Price: $0.006 USDC per successful call (x402, Solana). Same tool over HTTPS: POST https://scorptech.it.com/api/x402/v1/link-check

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": "link_check"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	Public http(s) page
`base`	No	Base URL for relative links in inline html
`html`	No	Inline HTML instead of url
`limit`	No	Links to check
`scope`	No		all
`assets`	No	Also check img / script / stylesheet / iframe URLs
`timeout`	No	Per-link timeout (ms)

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond annotations: discloses SSRF-safe fetching, HEAD with GET fallback, IP-pinned re-validation of every target, the 50-link cap and parallelism, the free/open-world nature implied by openWorldHint, plus the $0.006 USDC x402 payment requirement and an alternate HTTPS endpoint. Payment/auth requirements are exactly the kind of context annotations cannot convey.

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?

A dense but well-ordered paragraph: purpose first, then mechanics, then output format, then price/endpoint. Every clause is relevant, though the single run-on sentence is heavy and could be broken up for front-loading.

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, and the description compensates fully by enumerating returned fields (status, category enum, redirect location, response time, anchor text, broken-first ordering). For a 7-param, no-required-param tool, nothing an agent needs to invoke or interpret it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 86%, so the schema carries most parameter meaning. The description adds some behavioral color (limit capped at 50, optional assets, html-instead-of-url alternative) but says nothing about the 'base', 'scope', or 'timeout' parameters, so it does not meaningfully exceed the baseline.

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+resource ('Find broken links on a public web page') and immediately qualifies scope (or in supplied HTML). The distinguishing detail from sibling URL tools like url_links_extract is that it *checks* each link, not just extracts them, so an agent can pick correctly without opening sibling schemas.

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?

Provides concrete usage contexts: live public pages, or inline HTML drafts 'before publishing'. It does not explicitly name alternatives or exclusions (e.g. internal-only pages, private hosts), which keeps it short of a 5, but the context is clear enough to select it.

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

All ScorpTech x402 API 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?