Skip to main content
Glama
Sign In
fairquery-web

fairquery-web

Official
by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

HTTP security headers check with grade (free)

web_security_headers
Read-onlyIdempotent

Check a URL's HTTP security response headers, score configuration 0-100, and grade A-F to find missing or unsafe headers.

Instructions

Check HTTP security response headers of one URL: Strict-Transport-Security (>=180 days), Content-Security-Policy (flags unsafe-inline/unsafe-eval), X-Content-Type-Options (nosniff), X-Frame-Options (or CSP frame-ancestors), Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy; plus information-disclosure headers (Server, X-Powered-By). Weighted score 0-100 and grade A-F (non-HTTPS capped at 40). WHEN TO USE: quick security posture / hygiene check of a site. 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). One request (after redirects); headers are taken from the final response. RETURNS: one "security_headers" object: input, final_url, status_code, https, score, grade, headers[{header, present, value, warning, weight}], missing[], info_disclosure_headers[{header, value}], checked_at. Errors (isError=true, JSON {error, message, retryable}): INVALID_URL, BLOCKED_PRIVATE_ADDRESS, DNS_FAILED, FETCH_FAILED, TIMEOUT, TOO_MANY_REDIRECTS. WHEN NOT TO USE: not a vulnerability/penetration scan; for dependency CVEs use an OSV tool; for SEO use web_seo_audit. COST: free - runs locally in this MCP server (direct HTTP GETs), no APIFY_TOKEN, no Apify billing. PARAMETERS: url: headers are read from the FINAL response after up to 5 redirects, so "github.com" grades https://github.com/ - the redirecting hop itself is not graded. Path matters when a site sets different headers per path (e.g. "/login" vs "/"); test the exact page you care about. A bare domain is requested over https; pass "http://..." explicitly to see whether plain HTTP redirects to HTTPS - a final response over plain HTTP caps the score at 40 (grade D at best). Only response headers are evaluated (one request, body capped at 100 KB), never page content. EXAMPLE: {"url":"github.com"} -> {type:"security_headers", score:0-100, grade:"A".."F", missing:[...], ...}

Input Schema

NameRequiredDescriptionDefault
urlYesRequired. One public domain or http(s) URL (non-empty string), e.g. "github.com" or "http://example.com/login". Bare domains use https; headers come from the final response after redirects; private/loopback hosts are refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.4
    • changedInput schema / properties / url / description
      Previous value: -"Required. One public domain or http(s) URL, e.g. \"vercel.com\" or \"https://www.python.org/about/\". Bare domains are fetched over https; private/loopback hosts are refused."New value: +"Required. One public domain or http(s) URL (non-empty string), e.g. \"github.com\" or \"http://example.com/login\". Bare domains use https; headers come from the final response after redirects; private/loopback hosts are refused."
  2. Addedv1.2.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnly/openWorld/idempotent/non-destructive; the description adds substantial context beyond that: User-Agent, 15 s timeout, body cap, max 5 redirects, no JS rendering, SSRF refusal of private/loopback hosts, headers read from the final response, and a full error taxonomy. The only blemish is an internal inconsistency between the '1.5 MB HTML' and '100 KB' body caps.

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?

Long but front-loaded and cleanly sectioned (WHEN TO USE, RETURNS, WHEN NOT TO USE, COST, PARAMETERS, EXAMPLE), with each block earning its place. Minor redundancy and the conflicting body-cap figures keep it from a 5.

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?

No output schema, but RETURNS fully specifies the returned object shape and the error payloads, and the fetch/SSRF constraints are covered. An agent has everything needed to call and interpret this correctly.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the PARAMETERS section adds real meaning: redirecting hop is not graded, path-level differences matter, bare domains use https, and passing http:// explicitly reveals redirect behavior with a plain-HTTP score cap of 40.

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 ('Check HTTP security response headers of one URL') and enumerates exactly which headers are evaluated. It explicitly differentiates from siblings in WHEN NOT TO USE, routing CVE work to an OSV tool and SEO to web_seo_audit.

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?

Has an explicit WHEN TO USE ('quick security posture / hygiene check') and a WHEN NOT TO USE naming the alternatives and the reason. The agent knows both when to pick this tool and which sibling to pick instead.

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

Deploy Server

Other Tools