IntoDNS.ai DNS & Email Security Scanner

Scan and build Content-Security-Policy

scan_csp

Read-onlyIdempotent

Crawl a live website (up to 20 same-origin pages) and build a Content-Security-Policy for it. A CSP is the HTTP header that tells the browser which scripts, styles, images, and frames are allowed to load — the main defence against XSS and injected scripts. This scan reads the site's current CSP (header, report-only, or meta tag), flags problems a beginner might miss (no CSP at all, unsafe-inline, wildcard sources, missing object-src/base-uri/frame-ancestors), and inventories every external origin the site actually loads per directive. Returns: the detected current policy with issues, the per-directive origin inventory, a generated ready-to-deploy CSP in both report-only form (safe to roll out first) and enforce form, plus plain-language notes explaining each directive choice. Use this when the user asks to audit, analyze, or create a Content-Security-Policy for a real site, fix CSP console errors, or harden a site against XSS; use generate_security_headers for a generic best-practice header set without crawling. Slow: the crawl typically takes 30-45 seconds, so set expectations before calling. Rate-limited to 3 scans per 10 minutes per IP; repeat scans of the same origin within 10 minutes return the cached result instantly. Read-only — nothing on the site is changed.

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

Input Schema

Name	Required	Description	Default
`url`	Yes	The public website URL to crawl, e.g. https://example.com
`strict`	No	Generate a stricter policy (fewer broad allowances)

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds what annotations cannot: crawl depth (up to 20 same-origin pages), 30-45s duration, a 3-per-10-minute per-IP rate limit with 10-minute cached repeats, and that nothing on the site changes. It also enumerates what the crawl detects and returns, which is real behavioral context beyond the safety hints.

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?

Purpose is front-loaded in the first sentence and the usage/limits routing comes near the end, which is correct ordering. The explanatory sentence about what a CSP is ('the HTTP header that tells the browser...') is somewhat pedagogical for an agent audience, but it is a single sentence and the rest earns its place.

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?

With no output schema, the description carries the return contract fully: detected policy with issues, per-directive origin inventory, generated policy in report-only and enforce forms, plus plain-language notes. Combined with crawl limits, latency, and caching, an agent has everything needed to call it and set expectations.

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 description coverage is 100%, so both url and strict are already documented in the schema. The description implies date-scope-like constraints (same-origin crawling) that inform the url parameter but never mentions the strict flag or how it changes output, so it adds little beyond the schema 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?

Opens with a specific verb+resource ('Crawl a live website ... build a Content-Security-Policy') plus the scope limit of 20 same-origin pages. It explicitly names the sibling it is not, generate_security_headers, and contrasts crawling vs. a generic header set, so the agent can separate the two without opening schemas.

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 triggers ('audit, analyze, or create a CSP for a real site, fix CSP console errors, harden against XSS') and an explicit alternative with its own condition ('use generate_security_headers for a generic best-practice header set without crawling'). Timing and rate-limit caveats further guide the call decision.

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

All IntoDNS.ai DNS & Email Security Scanner 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.