fairquery-web

Official

by fairquery

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Quick URL check: status, redirects, title, speed (free)

web_quick_check

Read-onlyIdempotent

Check 1-20 URLs for reachability and redirects, returning final HTTP status, response time, content type, server header, and title. Use it to verify if sites are up or pre-filter leads.

Instructions

Lightweight reachability check for 1-20 URLs: final HTTP status, full redirect chain, response time (ms), content type, Server header and . WHEN TO USE: "is this site up?", "where does this domain redirect?", cheap pre-filtering of a lead list before deeper audits. For SEO details use web_seo_audit; for hundreds/thousands of sites use web_batch_audit. Fetching: GETs from this server with User-Agent "FairqueryBot ... Fairquery-MCP", 15 s timeout per request, body capped (1.5 MB HTML), max 5 redirects, no JavaScript rendering; URLs resolving to private/loopback/link-local addresses are refused (SSRF guard). Only the first 300 KB of each page is read. RETURNS: one "quick_check" or "error" row per input (error codes INVALID_URL, BLOCKED_PRIVATE_ADDRESS, DNS_FAILED, FETCH_FAILED, TIMEOUT, TOO_MANY_REDIRECTS); per-URL errors never fail the whole call. WHEN NOT TO USE: not for SEO/meta analysis (web_seo_audit), security headers (web_security_headers) or >20 URLs (web_batch_audit, paid). COST: free - runs locally in this MCP server (direct HTTP GETs), no APIFY_TOKEN, no Apify billing. PARAMETERS: urls: each entry is normalized independently and returns exactly one row, in input order: surrounding whitespace is trimmed, an entry without scheme gets "https://" (write "http://..." explicitly to test the plain-HTTP redirect), the #fragment is dropped, and the path/query are kept, so "vercel.com" and "vercel.com/pricing" are different checks. Entries that are not http(s), contain user:password@, have no dot in the host (e.g. "localhost") or resolve to private/loopback/link-local IPs become per-URL error rows (INVALID_URL / BLOCKED_PRIVATE_ADDRESS) while the other URLs still run; duplicates are fetched twice. All URLs are fetched in parallel, so total latency is roughly the slowest URL (max 15 s each). EXAMPLE: {"urls":["vercel.com"]} -> {count:1, items:[{type:"quick_check", final_url:"https://vercel.com/", status_code:200, ok:true, ...}]}

Input Schema

Name	Required	Description	Default
`urls`	Yes	Required. 1-20 non-empty strings, each a public domain or http(s) URL (bare domains use https; path kept, #fragment dropped). Example: ["vercel.com","http://github.com","https://www.python.org/about/"]

Output Schema

Name	Required	Description	Default
`count`	Yes	Number of rows returned
`items`	Yes	Result rows; each has a "type" field (data rows or machine-readable "error" rows)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.4Oct 18, 2026

changedInput schema / properties / urls / description

Previous value: -"Required. 1-20 public domains or http(s) URLs (bare domains use https), e.g. [\"vercel.com\",\"http://github.com\"]"New value: +"Required. 1-20 non-empty strings, each a public domain or http(s) URL (bare domains use https; path kept, #fragment dropped). Example: [\"vercel.com\",\"http://github.com\",\"https://www.python.org/about/\"]"

Addedv1.2.1Oct 17, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes far beyond the readOnly/idempotent annotations: it discloses User-Agent, 15 s timeout, 1.5 MB body cap, 5-redirect limit, no JS rendering, SSRF refusal of private/loopback addresses, parallel fetching, and that per-URL errors do not fail the whole call. That is exactly the operational context an agent needs before invoking.

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?

Well-labeled, front-loaded sections make a long description scannable and almost every sentence carries distinct information. There is minor redundancy (the free/local nature is restated as 'no APIFY_TOKEN, no Apify billing', and the SSRF guard is touched twice), which keeps it just short of a 5 for a one-parameter tool.

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?

Covers purpose, routing, fetch constraints, per-URL error taxonomy, cost model, parameter normalization and an example call. With an output schema also present, there is no gap an agent would need filled before calling this tool correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds real semantics on top: whitespace trimming, implicit https:// with explicit http:// to force plain-HTTP testing, fragment dropping, path/query retention, duplicate handling (fetched twice), and which entries become INVALID_URL / BLOCKED_PRIVATE_ADDRESS rows. These rules are not derivable from the schema alone.

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 and resource ('lightweight reachability check for 1-20 URLs') plus the exact outputs (status, redirect chain, response time, content type, Server header, title). It also distinguishes itself from web_seo_audit and web_batch_audit by name, so an agent can route without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit WHEN TO USE triggers ('is this site up?', 'where does this domain redirect?', pre-filtering leads), a WHEN NOT TO USE section naming the correct siblings (web_seo_audit, web_security_headers, web_batch_audit), and the threshold (>20 URLs) that switches tools. Nothing is left to inference.

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

Deploy Server