@true402.dev/mcp-server

headers_check

Fetch a URL and analyse its HTTP security headers (HSTS, CSP, X-Frame-Options, …) into present/missing + a 0–100 score. POST { url }; unpaid returns 402.

Instructions

Fetch a URL and analyse its HTTP security headers (HSTS, CSP, X-Frame-Options, …) into present/missing + a 0–100 score. POST { url }; unpaid returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.) Price: $0.003 USD (fixed).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "headers_check"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	The URL (http/https)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.1Jun 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden, and it discloses the important behavioral traits: outbound URL fetch, deterministic scoring output, and a paid x402 flow with a 402 on unpaid requests plus price and settlement chain. It stops short of rate limits, timeouts, or what happens on an unreachable/invalid URL.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what it does before the payment mechanics. Every clause carries information an agent needs — capability, request shape, payment gate, price — with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the work of explaining the return value (present/missing per header plus a 0–100 score), and it covers the payment prerequisite that would otherwise cause silent failure. Only failure-mode behavior beyond the 402 case is left unstated, which is minor for a one-parameter read-only check.

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% for the single required 'url' property, so the baseline is 3; the description adds slightly by specifying the URL is sent in a POST body as `{ url }` and noting http/https scope consistent with the schema. No further semantics (e.g. redirect handling, query strings) are added.

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?

Specific verb + resource + output: 'Fetch a URL and analyse its HTTP security headers … into present/missing + a 0–100 score.' The named header set (HSTS, CSP, X-Frame-Options) makes it unmistakably distinct from siblings like robots_check, seo_audit, or screenshot, and the return shape is stated up front.

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?

Gives clear invocation context — 'POST `{ url }`', 'unpaid returns 402', and a fixed $0.003 price with the funding prerequisite for the MCP wallet. That is strong operational guidance for whether the agent can actually call it, though it never states when to prefer this over the adjacent robots_check or seo_audit tools.

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