AttackerView quick website security check

Quick website security check

check_website_security

Read-onlyIdempotent

AttackerView's quick website security check: reports problems with a domain's security headers, HTTP to HTTPS redirect, DNS, email authentication and TLS. Use when the user asks things like 'is example.com secure?' or 'are my security headers, SSL, SPF or DMARC set up right?'. Passive check in seconds: one homepage request. No login, crawling or attacks, so it cannot find application vulnerabilities.

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": {
      "domain": "<domain>"
    },
    "name": "check_website_security"
  }
}

Input Schema

Name	Required	Description	Default
`domain`	Yes	Domain or URL, e.g. example.com. Only the hostname is used.

Output Schema

Name	Required	Description
`domain`	Yes
`issues`	Yes	Problems found, most severe first.
`passed`	Yes	Titles of checks that passed.
`checked`	Yes	Checks that finished. Anything not listed was not checked.
`notTested`	Yes	What this check did not test. Tell the user this whenever you report the result.
`reachable`	Yes	Whether the homepage answered. When false, only DNS, email and TLS were checked.
`fullScanUrl`	Yes	Full AttackerView scan of this domain: crawls the site and tests the application itself.
`whatWasNotTestedUrl`	Yes	Page that explains what this check looks at and what it cannot see. Give the user this link.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 10, 2026

addedOutput schema / properties / notTested

Added value: +{
+  "description": "What this check did not test. Tell the user this whenever you report the result.",
+  "type": "string"
+}

addedOutput schema / properties / whatWasNotTestedUrl

Added value: +{
+  "description": "Page that explains what this check looks at and what it cannot see. Give the user this link.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "domain",
-  "reachable",
-  "checked",
-  "issues",
-  "passed",
-  "fullScanUrl"
-]New value: +[
+  "domain",
+  "reachable",
+  "checked",
+  "issues",
+  "passed",
+  "notTested",
+  "whatWasNotTestedUrl",
+  "fullScanUrl"
+]

First observedNov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered; the description still adds real value beyond them by disclosing the execution model ('passive check in seconds: one homepage request') and confirming no login, crawling or attacks are performed. It also bounds the result quality by stating the tool cannot detect application-level vulnerabilities.

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 sentences, each earning its place: identity and coverage first, then usage triggers, then behavioral limits. No repetition of the title or annotations, and the most decision-relevant information is front-loaded.

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?

An output schema exists, so return-value explanation is unnecessary, and the single required parameter is fully documented in the schema. For a passive, read-only, single-input check, the description supplies everything an agent needs to select and call it correctly, including its limitations.

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?

With one parameter at 100% schema description coverage, the schema already explains that a domain or URL is accepted and that only the hostname is used. The description reinforces the input through the 'example.com' usage examples but adds no format, normalization or edge-case detail beyond the schema, so the baseline 3 applies.

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 ('reports problems') against a precisely enumerated resource set: security headers, HTTP-to-HTTPS redirect, DNS, email authentication (SPF/DMARC) and TLS. Scope boundaries are named explicitly ('one homepage request', 'cannot find application vulnerabilities'), so an agent knows exactly what class of check this is without opening the 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 concrete trigger phrasings ('is example.com secure?', 'are my security headers, SSL, SPF or DMARC set up right?') that map user intent directly to this tool, and pairs them with an explicit non-use case: it cannot find application vulnerabilities. That covers both when to use and when not to, leaving little to infer.

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

All AttackerView quick website security check 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?