What can you do with this server?

The urlscan-mcp server provides access to urlscan.io for URL scanning, retrieval, search, assessment, and account/capability checks, with summarized, model-friendly responses. * Scanning: Submit a URL with scan_url (returns UUID) or scan_and_wait (submit/poll/summarize). Optional tags, country, user agent, referer, visibility. * Retrieval: get_scan_result (summarized or full), get_page_dom (DOM snapshot), get_screenshot_url. * Search: search_scans (ElasticSearch queries), and dedicated searches by domain, IP, ASN, or SHA-256 hash. * Assessment: assess_indicator for domain, IP, URL, or hash, with aggregate scan stats, risk signals, and distinction between no data/no findings. * Account & capabilities: get_quotas, list_available_countries, server_capabilities. * Key requirements: Scanning, result fetching, DOM, and quota checks require an API key; search and assessment work without a key with caveats. * Efficiency: Summarized responses by default; use full=True for raw documents; automatic degradation when no API key is configured.

How do I use urlscan-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@urlscan-mcp scan https://example.com and summarize the results" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

urlscan-mcp

by blackhole8080-darkmatter

Overview Schema Related Servers Score Discussions

Python

Remote

urlscan-mcp

An MCP server for the urlscan.io API. Scan URLs, search the historical scan corpus, and assess indicators from Claude Code, Claude Desktop, Cursor, or any other MCP client.

Fifteen tools. Cached reads. Sees the page. Python 3.10+. MIT.

Why another one

The existing urlscan MCP servers expose roughly one tool — "scan a URL" — and return the raw API response. That is a problem in practice, because a urlscan result document is frequently several megabytes: every request, every response header, every cookie. Handed to a model verbatim it swallows the context window and buries the handful of facts anyone wanted.

This server is built around five decisions:

Responses are shaped, not forwarded. Every tool returns a summary built for a model to reason over. The raw document stays one full=True away. Measured against live scans of a news site: 2.7 MB → 3.3 KB, a 812× reduction, on a page making 244 requests. Three real scans came in at 240×, 571× and 812×.
It degrades instead of failing. Search and the country list work with no API key at all. server_capabilities reports exactly what is available, so the model never has to discover a limitation by hitting it.
It never implies safety it cannot evidence. The search API returns no verdict data at all — with or without a key. A tool that reads a missing verdict as "clean" reports every malicious indicator on earth as safe, so this one distinguishes no data from no findings, everywhere, and falls back to signals it can actually observe: apex domain age, Umbrella popularity rank, and submitter tags.
Reads are cached, and a sample says it is one. Scans are immutable once written, so GETs are held for an hour — an agent pivoting around one investigation asks the same question repeatedly, and the free tier should not be spent on answers already known. Submissions are never cached: replaying one would hand back a scan id for a scan that never ran. And when more scans match than the API's 100-per-page cap returns, assess_indicator sets sampled and says so, because a sample presented as a total is the same class of error as a missing verdict presented as clean.
Domain and URL lookups match redirectors. urlscan records the submitted URL under task.* and the final, post-redirect page under page.*. Querying page.* alone — which is what the obvious implementation does — silently misses every domain that redirects away, and redirecting away is exactly what link shorteners, phishing redirectors and traffic distribution systems do. Verified against the live API: page.domain:lzphy.top returns zero hits while task.domain:lzphy.top returns the scan, because the page redirected to github.com. Reporting "no scans found" for an indicator that has been scanned is the same failure as reading a missing verdict as "clean", so both lookups query (page.X OR task.X).
The trap is what comes next. A redirected scan's page.* fields describe the destination, so reading apex domain age or Umbrella rank off them credits the indicator with someone else's reputation — lzphy.top inherited github.com's 13-year age and rank 1508, which in turn suppressed the "no established traffic" risk signal. assess_indicator therefore derives reputation only from scans that actually landed on the indicator, reports scans_redirected_away and redirect_destinations separately, and says explicitly when no signal can be attributed. Manufacturing a good reputation is a worse failure than withholding a verdict.

Related MCP server: Cyberbro MCP Server

Install

git clone <this repo>
cd urlscan-mcp
pip install -e .

Optional but recommended — a free API key from urlscan.io/user/signup:

cp .env.example .env   # then set URLSCAN_API_KEY

Pointing at a self-hosted urlscan appliance instead of the public service is URLSCAN_BASE_URL=https://urlscan.internal.example. Both the API calls and the screenshot fetches follow it — they read one setting, so an instance cannot be half-configured — and server_capabilities then says which host it is talking to, because the caveats these tools attach describe urlscan.io's corpus and verdicts, not somebody else's.

Claude Code

claude mcp add urlscan --env URLSCAN_API_KEY=your_key_here -- python -m urlscan_mcp.server

Claude Desktop / Cursor

Add to your MCP config:

{
  "mcpServers": {
    "urlscan": {
      "command": "python",
      "args": ["-m", "urlscan_mcp.server"],
      "env": { "URLSCAN_API_KEY": "your_key_here" }
    }
  }
}

What needs a key

Verified against the live API on 2026-08-03 — note this differs from what the public docs imply, which is why server_capabilities exists.

Works without a key	Requires a key
`search_scans` and all `search_by_*`	`scan_url`, `scan_and_wait`
`list_available_countries`	`get_scan_result`, `get_page_dom`
`assess_indicator`	`get_quotas`
`get_screenshot_url`	verdicts (present in results only)
`analyze_screenshot`

Verdicts never appear in search responses on the free plan, key or not — only in individual result documents. assess_indicator runs on search, so it reports verdicts.available: false and reasons from observable signals instead. That is deliberate, and the reason is in the tool's own output.

Tools

Scanning

scan_url — submit a URL, return immediately with a UUID
scan_and_wait — submit, poll, and return the finished summary in one call

Retrieval

get_scan_result — summarised scan result (full=True for the raw document)
get_page_dom — captured DOM, truncated
get_screenshot_url — screenshot and report links, for a human to open
analyze_screenshot — the page itself, as an image your model can read

Search

search_scans — raw ElasticSearch query string
search_by_domain — a domain and its subdomains
search_by_ip — what else was served from an address
search_by_asn — everything within an autonomous system
search_by_hash — pivot from a known-bad resource to every page serving it

Assessment

assess_indicator — aggregate every recent scan of a domain, IP, URL or SHA-256 into one reputation picture, with explicit caveats

Account

get_quotas, list_available_countries, server_capabilities

Example

> assess_indicator for the domain in this phishing report

{
  "indicator": "…",
  "scans_found": 92,
  "verdicts": {
    "available": false,
    "note": "urlscan.io did not return verdict data for these scans. This is
             normal without an API key. It does NOT mean the indicator is clean."
  },
  "reputation_signals": {
    "min_apex_domain_age_days": 6,
    "ranked_in_umbrella": false
  },
  "risk_signals": [
    "Apex domain is very young (6 days) — common in phishing.",
    "Not present in the Umbrella popularity ranking — no established traffic.",
    "Submitters tagged scans with 'phishing'."
  ],
  "assessment": "No malicious verdict across 92 scan(s), but the apex domain is
                 only 6 days old and it has no Umbrella popularity ranking.
                 Treat as unproven rather than benign."
}

Seeing the page

Every other tool returns metadata about a page. analyze_screenshot returns the page. Domain age and popularity rank say a site is suspicious; only looking at it says this is a Microsoft 365 sign-in form — which is the question someone triaging a phishing report is actually asking. It needs no API key.

The model doing the looking is your client's, not a second vendor's. MCP carries images natively, so the screenshot comes back as image content and whatever multimodal model is driving the session reads it. No extra key, no extra bill, and the analysis improves when your model does.

What ships with the image matters as much as the image:

A brand is not a verdict. A real Microsoft login page and a perfect clone are the same pixels. What makes one phishing is the brand not matching the domain serving it — so the domain travels with the picture and the instruction says to compare them. Told only "look for phishing", a model reports every login form it sees.
A redirect is surfaced. Judging the brand against the submitted domain after a scan bounced elsewhere compares the page to a host that never served it.
With no domain, the comparison is refused rather than faked. The scan's domain comes from its result document, which needs a key — the screenshot does not. Keyless, the brief used to ask whether the brand matched "unknown", and a model answers that anyway. It now says the comparison cannot be made and names the two ways to close it. Pass domain= if you already know which host you are investigating; it travels marked as your claim, not the scan's record.
One fetch, one country, one moment. Cloaked pages serve scanners something bland and victims something else, and a blank capture usually means blocked rather than safe.
The image is attacker-controlled. Text rendered into a page can carry instructions aimed at whatever reads it. The brief says so explicitly rather than hoping.

Install Pillow (pip install 'urlscan-mcp[vision]') and full-page captures are cropped to the part that matters and downscaled before they reach the model — a 1920×9000 capture goes out at roughly a fifth the bytes. Without Pillow the image still goes out, unmodified, with a note saying so.

Using it as a library, not just a server

The rules that make this server's output trustworthy — no verdict data is not a clean verdict, and only scans that landed on the indicator may lend it their reputation — are worth more than the transport around them. They live in two modules that import no mcp and perform no I/O:

urlscan_mcp.query — indicator classification and ElasticSearch query construction, including the (page.X OR task.X) redirector matching.
urlscan_mcp.assess — build_assessment(), which turns shaped search hits into the same dictionary assess_indicator returns.

So an application with its own HTTP stack — its own cache, rate limiting and failure isolation — can reach the same conclusions without either running a subprocess or reimplementing the judgment:

from urlscan_mcp import query, assess
from urlscan_mcp.shaping import summarize_search_hit

kind, q = query.classify("lzphy.top")
raw = my_http.get_json(f"https://urlscan.io/api/v1/search/?q={q}&size=100")
hits = [summarize_search_hit(h) for h in raw["results"]]

report = assess.build_assessment("lzphy.top", kind, hits, days=180)

DEEP consumes it exactly this way, alongside running this server over stdio — the two paths share one implementation of the analysis rather than drifting apart.

Development

pip install -e ".[dev]"
pytest

A live check is python live_check.py [domain-or-url] — it exercises what offline tests cannot, and reaches a verdict rather than printing numbers to squint at. It measures every screenshot the sample offers and then says, for each of MAX_IMAGE_BYTES, MAX_ASPECT_RATIO and TARGET_WIDTH, whether the value is doing its job: a ceiling nothing reaches has headroom, a ceiling everything reaches is too low, and a crop that fires on every page is below the normal page rather than above it. Those three numbers were chosen against synthetic images, so this is how they get checked against real ones. No key needed for the search and screenshot parts. It is itself covered by tests/test_live_check.py, which drives it against a local stand-in — a script whose whole purpose is to be run rarely, by hand, is the one most likely to have rotted by the time you run it.

84 offline tests — no network, no key required. They cover query escaping, redirector matching (page.* vs task.*), input validation, auth degradation, response shaping against malformed documents, and the assessment logic's refusal to imply safety — including build_assessment directly, since embedding applications depend on those guarantees too.

Limits

Verdict-based search (verdicts.score:>50) requires a paid urlscan plan and returns HTTP 403 otherwise.
Structure and similarity search are Pro-only and are not wrapped here.
assess_indicator reads the last 100 matching scans, not the full history.
urlscan verdicts are heuristic and community-influenced. Nothing here is ground truth, and the tools say so in their own output rather than leaving the model to infer it.
Cloaked pages routinely serve different content to scanners than to victims. A clean scan is evidence about one fetch, from one country, at one time.

Who built this

I build MCP servers and LLM agent integrations against real systems. If you have an internal API your team would want to drive from Claude, Cursor, or any other MCP client, that is a fixed-price, five-day job — aryan.kshir10@gmail.com.

Also: DEEP, a local-first AI assistant with a cybersecurity engine, MIT.

MIT. Not affiliated with urlscan.io.

Available Tools

14 tools

assess_indicatorA

Build a reputation picture for a domain, IP, URL or SHA-256 hash.

Aggregates every recent urlscan.io scan of the indicator into one assessment: how often it has been scanned, how many scans were flagged malicious, the highest and mean verdict scores, which tags and brands recur, and the hosting spread.

This is analysis on top of the raw API rather than a passthrough — it answers "should I care about this?" instead of returning a scan document. Read the caveats field before acting on the result.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No
`indicator`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool aggregates recent scans, computes specific statistics (malicious count, verdict scores, recurring tags/brands, hosting spread), and warns to read the caveats field before acting. This gives meaningful insight into the tool's behavior beyond a simple 'assess' action.

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?

The description is tightly written with no filler. It front-loads the purpose, then adds useful detail about the computed stats and concludes with an important caveat warning – every sentence contributes.

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?

The tool is moderately complex, and the description covers its core analysis, accepted indicator types, and the caveats field. However, it omits explanation of the 'days' parameter, which is a minor gap given the output schema exists and the rest is well described.

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 coverage is 0%, so the description must explain parameters. It clarifies that the indicator parameter accepts domains, IPs, URLs, or SHA-256 hashes, but does not mention the 'days' parameter or its default of 180. Since the description partially compensates but leaves 'days' undocumented, a 3 is appropriate.

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?

The description opens with a specific verb ('Build a reputation picture') and clearly scopes the resource to domains, IPs, URLs, or hashes. It explicitly distinguishes itself from passthrough tools by stating it provides aggregated analysis, setting it apart from scan lookup siblings.

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?

The description implies usage when an aggregated reputation assessment is needed, contrasting with raw passthrough. However, it does not explicitly name alternative tools or state when not to use it, so context is clear but exclusions are absent.

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

get_page_domA

Fetch the captured DOM snapshot for a scan. Requires an API key.

Useful for inspecting injected scripts, hidden form fields, or obfuscated payloads. Truncated to max_chars — full DOMs regularly exceed 1 MB.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes
`max_chars`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description discloses key behaviors: it requires an API key, truncates to max_chars, and notes that full DOMs regularly exceed 1 MB. This gives the agent important operational context beyond the schema, though it does not cover edge cases like missing DOM snapshots.

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?

The description is brief, front-loaded with the main purpose, and every sentence adds value (use cases, API key, truncation/scale). No unnecessary filler or repetition of schema details.

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?

Given the tool's moderate complexity and presence of an output schema, the description provides sufficient context: what it does, when to use it, and critical behavioral caveats. It misses a direct note about the uuid semantics, but overall it is complete enough for an agent to select and invoke the tool correctly.

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

Parameters2/5

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

The description mentions max_chars and explains truncation, but does not clarify the meaning of the required 'uuid' parameter, which is essential for invocation. Since schema description coverage is 0%, the description must compensate more, and it only partially does so for max_chars, not uuid.

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?

The description clearly states 'Fetch the captured DOM snapshot for a scan,' identifying the specific resource and action. It distinguishes this tool from siblings like get_scan_result and get_screenshot_url by focusing on the DOM snapshot, making its purpose unambiguous.

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?

The description provides clear usage context with 'Useful for inspecting injected scripts, hidden form fields, or obfuscated payloads,' but does not explicitly mention when not to use this tool or name alternatives. This is clear context without exclusions, fitting a score of 4.

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

get_quotasA

Show remaining urlscan.io API quota for the configured key.

Worth checking before a batch of scans. Requires an API key.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It states this is a read-only quota display and requires an API key, but does not explicitly confirm it consumes no quota or describe edge cases like missing/invalid keys.

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?

Two short, front-loaded sentences. The first states the core purpose, the second adds practical usage guidance. No wasted words.

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?

Given a simple no-param tool with an output schema, the description covers purpose, timing, and prerequisite clearly. It is complete for the tool's complexity.

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?

There are zero parameters and schema coverage is 100%, so there is no param semantic burden. The baseline for zero params is 4, and the description needs no further parameter detail.

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?

The description clearly states it shows remaining urlscan.io API quota for the configured key. This is a specific verb+resource combo that distinguishes it from the many scanning and search sibling tools.

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?

It explicitly says 'Worth checking before a batch of scans', giving clear context for when to use it. It also notes the API key prerequisite, but does not mention when not to use it or alternatives.

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

get_scan_resultA

Fetch the result of a completed scan by UUID. Requires an API key.

Returns a summary by default. Set full=True for the complete document — be aware that it is frequently several megabytes and will dominate the context window.

ParametersJSON Schema

Name	Required	Description	Default
`full`	No
`uuid`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the need for an API key, the default summary response, and the important behavior that full=True can return a multi-megabyte document that may dominate the context window. It does not cover error handling or rate limits, but the disclosed details are valuable.

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?

The description is two sentences, front-loaded with the core purpose, and every sentence adds value. The warning about size is concise and actionable.

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?

For a simple retrieval tool with an output schema, the description is sufficient. It covers the purpose, auth requirement, default behavior, and a critical caveat about large responses. The output schema handles return value details.

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?

The schema has 0% coverage, so the description must add meaning. It clarifies that uuid identifies the scan and explains that full controls whether a complete document is returned instead of a summary, including the consequence of setting it to true. This goes beyond the bare parameter names.

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?

The description clearly states 'Fetch the result of a completed scan by UUID', which is a specific verb+resource combination. It distinguishes this from sibling tools like search_scans (which searches) and scan_url (which initiates scans).

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?

The phrase 'completed scan' implies the tool should be used after a scan has finished, and the warning about setting full=True for the complete document provides practical guidance. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.

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

get_screenshot_urlA

Get the screenshot URL for a scan.

Returns a link rather than image bytes — screenshots are large and usually meant for a human to open.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the tool returns a URL instead of binary image data, and explains why. This adds meaningful context. It does not cover error handling or authentication, but for a simple getter tool, the transparency is solid.

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?

The description is two sentences, front-loaded with the purpose, and every sentence adds value. The second sentence justifies the return type without any fluff, achieving maximum conciseness.

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

Completeness3/5

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

For a simple one-parameter tool, the description adequately states the purpose and return behavior, and the presence of an output schema likely covers return structure. However, it lacks any parameter description and does not mention prerequisites, potential errors, or whether the URL is temporary, making it only minimally complete.

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

Parameters2/5

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

The schema has only one parameter, 'uuid', with 0% description coverage, and the tool description does not explain what the uuid represents beyond the generic phrase 'for a scan'. It adds no details about format, required context, or how to obtain the uuid, leaving the agent to infer from the parameter name and tool name.

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?

The description clearly states the tool gets a screenshot URL for a scan, with the verb 'Get' and specific resource 'screenshot URL'. It further distinguishes itself by explaining it returns a link rather than image bytes, setting it apart from sibling tools like get_scan_result or get_page_dom.

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?

The description provides clear usage context by stating that screenshots are large and 'meant for a human to open', implying this tool is appropriate when a human will view the image. However, it does not explicitly mention alternative tools or exclusion scenarios, so it falls short of a 5.

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

list_available_countriesA

List country codes available as scanner exit locations.

Geo-targeted phishing frequently only serves the payload to one region, so re-scanning from the right country is often what makes it visible.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior (listing country codes) but doesn't add details about authentication, rate limits, or other potential side effects. The phishing rationale is more about usage guidance than behavioral transparency.

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?

The description is two concise sentences: the first states the core function, and the second offers a relevant rationale. It is well-structured and front-loaded with no unnecessary words.

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?

For a zero-parameter tool with an output schema present, the description is sufficient. It explains what the tool does and why it is useful, allowing an agent to correctly select and invoke it without further clarification.

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?

The tool has zero parameters, so the baseline of 4 applies. No parameter explanations are needed since there are none.

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?

The description explicitly states 'List country codes available as scanner exit locations' with a specific verb and resource. It clearly distinguishes itself from sibling scanning/search tools by focusing on available countries.

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?

The description provides clear context by explaining the geo-targeted phishing scenario and how re-scanning from the right country helps. While it doesn't explicitly name alternatives or exclusions, the intended use case is effectively communicated.

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

scan_and_waitA

Submit a URL and wait for the finished, summarised result.

This is the tool to reach for in most workflows — it handles the submit, poll and summarise cycle in one call. Requires an API key.

ParametersJSON Schema

Name	Required	Default
`url`	Yes
`tags`	No
`country`	No
`visibility`	No	public
`timeout_seconds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description must carry the transparency burden. It discloses the submit-poll-summarize behavior and API key requirement, but it does not mention side effects like scan creation or quota consumption, nor does it explain blocking/timeout behavior beyond the default timeout parameter. This is moderate transparency.

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?

The description is three concise sentences, front-loaded with the core action and outcome. Every sentence adds value: the action, the usage guidance, and the authentication requirement. No filler.

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

Completeness3/5

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

The presence of an output schema means return values don't need explanation. However, with no annotations and zero parameter description coverage, the description misses important context about optional parameters and side effects. It is adequate for a default workflow but incomplete for full parameter understanding.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only mentions 'URL' and gives no explanation of tags, country, visibility, or timeout_seconds. The defaults in the schema provide some implicit meaning, but the description adds little beyond restating the primary input.

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?

The description uses a specific verb and resource: 'Submit a URL and wait for the finished, summarised result.' It clearly distinguishes the tool from siblings by noting that it handles the full submit, poll, and summarise cycle in one call, unlike separate scan_url or get_scan_result steps.

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?

It explicitly says this is the tool to reach for in most workflows and describes the combined cycle, which gives clear context for when to use it. It does not explicitly state when not to use it or mention alternatives, so it stops short of a 5.

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

scan_urlA

Submit a URL to urlscan.io for scanning. Returns immediately with a UUID.

The scan takes roughly 10-30 seconds to complete. Use scan_and_wait instead if you want the finished result in one call.

Requires an API key. visibility must be one of: public, unlisted, private. country is a 2-letter ISO code selecting the scanner's exit location.

ParametersJSON Schema

Name	Required	Default
`url`	Yes
`tags`	No
`country`	No
`referer`	No
`user_agent`	No
`visibility`	No	public

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does a good job: it discloses the asynchronous behavior (immediate UUID return, 10-30 second completion), the API key requirement, and the visibility values. It lacks details on permission side-effects or potential failures, but overall it is notably transparent for a submission tool.

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?

The description is compact, front-loaded with the action, and every sentence contributes value: purpose, behavior, alternative tool, and key constraints. No filler or redundancies.

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?

Given the tool's moderate complexity and the existence of an output schema, return values don't need explaining. The description covers the core purpose, async behavior, alternative, and the most critical parameters. However, it leaves several parameters unexplained and does not mention how the scan result will be retrieved, such as via get_scan_result, which would improve completeness.

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?

Input schema coverage is 0%, so the description must compensate, but it only explains two of six parameters: visibility (enum) and country (ISO code). The url, tags, referer, and user_agent parameters are not described, leaving the agent to infer their meaning from names and purpose. This partial compensation meets a minimum viable level but not more.

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?

The description clearly states the primary action: 'Submit a URL to urlscan.io for scanning.' It further specifies the immediate return with a UUID and distinguishes itself from the sibling tool scan_and_wait, making the purpose unambiguous and specific.

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?

Explicitly directs users to use scan_and_wait instead when they want the finished result in a single call, directly addressing when to use this tool vs. an alternative. Also provides temporal context (10-30 second scan duration) that helps select this async option.

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

search_by_asnA

Find recent scans hosted within an autonomous system, e.g. 'AS15169'.

ParametersJSON Schema

Name	Required	Description	Default
`asn`	Yes
`days`	No
`size`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only says 'Find recent scans' without disclosing that this is a read-only operation, the meaning of 'recent' (tied to the days parameter), result size limits, or any other behavioral traits. This is a significant gap.

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?

The description is a single sentence, front-loaded with the action and target, and includes an example. There is no wordiness or redundancy.

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

Completeness3/5

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

Given the tool has three parameters and an output schema, the description provides the core purpose but omits context about default time range, result pagination, and how it relates to sibling search tools. It is adequate but minimal.

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

Parameters2/5

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

The example 'AS15169' gives a format hint for the asn parameter, but there is no explanation of the days or size parameters. With schema description coverage at 0%, the description fails to compensate for the missing parameter documentation.

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?

The description clearly states the tool finds recent scans within an autonomous system, using an example ASN ('AS15169'). This specifies a unique verb+resource+scope, distinguishing it from sibling search tools like search_by_domain, search_by_ip, and search_by_hash.

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?

The description gives clear context that this tool is for ASN-based search, making it obvious when to use it. However, it does not explicitly exclude alternatives or mention when not to use it, so it falls short of a 5.

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

search_by_domainB

Find recent scans of a domain. Matches the domain and its subdomains.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No
`size`	No
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds only that the search matches subdomains, but omits important behavior such as the meaning of 'recent' (e.g., time window), result ordering, pagination, or its read-only nature. This is insufficient for a tool with zero annotation support.

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?

The description is exceptionally concise, consisting of two short sentences with no redundant information. Every word contributes to the purpose, and the subdomain-matching detail adds behavioral value without bloating the text.

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

Completeness3/5

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

This is a relatively simple search tool with an output schema, but the description lacks usage guidelines and parameter semantics. It covers the core purpose and a key behavioral trait (subdomain matching), yet leaves gaps that could confuse an agent trying to invoke it correctly, especially given the 0% schema description coverage.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for missing parameter documentation. It does not explain 'domain', 'days', or 'size' beyond a vague hint that scans are 'recent'. The defaults are present in the schema but their meaning is left to inference, which is inadequate at this coverage level.

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?

The description uses a specific verb 'Find' and clearly identifies the resource as 'recent scans of a domain', with an explicit note that it matches the domain and its subdomains. This distinguishes it from sibling tools like search_by_ip, search_by_asn, and search_by_hash, which target different resource types.

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

Usage Guidelines2/5

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

No guidance is provided on when to prefer this tool over alternatives such as search_scans, search_by_ip, or search_by_asn. The description implies domain-based search but does not state prerequisites, exclusions, or a comparison with sibling tools.

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

search_by_hashA

Find scans that loaded a resource with this SHA-256 response hash.

Pivots from one known-bad file to every other page serving it — often the fastest way to map a campaign.

ParametersJSON Schema

Name	Required	Description	Default
`size`	No
`sha256`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description must carry the behavioral transparency burden. It makes clear the operation is a read-only search ('Find scans'), and adds useful context about pivoting from a hash to pages. However, it does not explicitly state that this is a read-only operation or mention any potential limitations (e.g., rate limits, whether results are limited by the 'size' parameter).

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?

The description is two sentences long, front-loads the core function, and adds a concise, valuable use case in the second sentence. Every word contributes meaning; there is no redundancy or fluff.

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?

The tool is a simple hash-based search with an output schema, so the description does not need to explain return values. It covers the purpose, the input, and a recommended scenario well. Minor gap: it does not mention the optional 'size' parameter or any search constraints (e.g., time range), but those are partially addressed by the schema and output schema.

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 0%, so the description must compensate for parameter meaning. It explains the 'sha256' parameter clearly as a 'SHA-256 response hash' of a resource. However, it does not mention the 'size' parameter at all, even though its meaning might be inferred from its name and default value.

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?

The description clearly states the tool finds scans that loaded a resource with a specific SHA-256 response hash, using the verb 'Find' plus a specific resource type. It distinguishes itself from sibling search tools (search_by_domain, search_by_ip, search_by_asn) by focusing on a hash pivot, and adds a strategic use case ('map a campaign').

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?

The description provides clear context for when to use the tool: when you have a known-bad file hash and want to find all pages serving it, often the fastest way to map a campaign. It does not explicitly mention alternative tools or when not to use it, but the context is strong enough to guide appropriate usage.

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

search_by_ipA

Find recent scans of pages served from an IP address.

Good for spotting what else is hosted alongside something suspicious.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes
`days`	No
`size`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It communicates that results are 'recent scans' and that only pages served from the IP are included, which is useful. But it does not mention potential side effects, rate limits, or that it is a read-only operation, leaving some gaps in transparency.

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?

The description is two sentences long, with the first sentence front-loading the core function and the second sentence adding practical value. Every word earns its place; there is no redundancy or fluff, making it highly concise and well-structured.

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?

The tool is relatively simple, and the description covers its primary function and use case. Since an output schema exists, return-value details are not required. However, parameters like 'days' and 'size' are left entirely to the schema, and the lack of annotations means the description could provide more operational context, such as default behavior or limitations.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only alludes to the 'ip' parameter via the tool name and description, and gives no explicit meaning for 'days' (lookback period) or 'size' (result limit). The word 'recent' hints at days, but the guidance is too vague to be helpful.

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?

The description clearly states the tool's function: 'Find recent scans of pages served from an IP address.' It uses a specific verb and resource, and the IP focus distinguishes it from sibling tools like search_by_domain or search_by_asn. The additional use case about spotting co-hosted content reinforces its unique purpose.

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?

The description provides a clear usage context: 'Good for spotting what else is hosted alongside something suspicious.' This implies when to use the tool (when investigating a suspicious IP). However, it does not explicitly mention alternatives or exclusions, so it stops short of a perfect score.

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

search_scansA

Search historical urlscan.io scans with an ElasticSearch query string.

Useful fields: page.domain, page.ip, page.asn, page.server, page.status, domain, ip, asn, country, hash, filename, task.tags, verdicts.score, verdicts.malicious, date.

Examples: page.domain:example.com AND page.status:200 task.tags:phishing AND date:>now-30d verdicts.score:>50 AND page.asn:AS15169

Works without an API key, at lower rate limits.

ParametersJSON Schema

Name	Required	Description	Default
`size`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the burden of disclosing behavioral traits. It adds useful context by stating 'Works without an API key, at lower rate limits,' which informs about authentication and rate constraints. However, it does not elaborate on other behaviors such as pagination, sorting, or any limits on the 'size' parameter. The rate-limit mention adds significant value, but not enough for a higher score.

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?

The description is concise and well-structured: a one-sentence definition, followed by a curated list of useful fields, then three concrete examples. Every part contributes to understanding how to invoke the tool. It is appropriately sized for the complexity and avoids redundant or extraneous information.

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?

The tool has an output schema, so return values are already specified. The description covers the main functionality, query syntax, useful fields, and even rate-limit behavior. It is complete enough for an AI agent to construct valid queries, though it could have briefly mentioned that it's the general-purpose alternative to the specialized search tools. The examples and field list make it largely sufficient.

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?

The schema has 0% description coverage, so the description compensates by providing a detailed field list and query examples that clarify the syntax and semantics of the 'query' parameter. While the 'size' parameter is not described, it has a default and is self-explanatory. The query examples offer meaning well beyond the bare schema type, leading to a score of 4.

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?

The description clearly states the tool's function: 'Search historical urlscan.io scans with an ElasticSearch query string.' This specifies the verb, resource, and method, and distinguishes it from sibling tools like 'search_by_domain' or 'search_by_ip' by emphasizing the flexible ElasticSearch query capability. The inclusion of useful fields and examples reinforces the purpose.

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?

The description gives clear context on how to use the tool through examples and a list of searchable fields, making it apparent that this is for ad-hoc, query-based searching rather than specific lookups like by domain or IP. It does not explicitly state when not to use it or name alternatives, but the sibling names and the tool's generic nature imply appropriate usage. There is no exclusion guidance, so a 4 is appropriate.

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

server_capabilitiesA

Report which operations are available with the current configuration.

Submission and quota lookup need an API key; search and result retrieval do not. Call this first if something is unexpectedly refused.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It adds valuable behavioral context by disclosing that submission and quota lookup need an API key while search and result retrieval do not, and it suggests using the tool for troubleshooting refusals. It stops short of explicitly stating read-only behavior, but the nature of a 'report' implies it.

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?

The description is concise (two sentences), front-loaded with the core purpose, and every sentence adds meaningful value. The second sentence provides essential usage context without redundancy.

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?

Despite having no parameters, the description fully covers the tool's purpose, usage conditions, and operational context. With an output schema present and low complexity, the description is sufficiently complete for an agent to select and invoke the tool 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?

The tool has zero parameters, so per the rubric the baseline is 4. The description does not need to add parameter-level detail, and the schema already covers the empty parameter set fully.

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?

The description uses the specific verb 'Report' and identifies the resource as 'operations available with the current configuration.' This clearly states what the tool does and distinguishes it from sibling tools like scan_url or get_quotas, which perform different actions.

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?

Explicitly explains when to call this tool ('Call this first if something is unexpectedly refused') and provides concrete context about API key requirements for different operation types. This gives clear guidance on usage and when to prefer it over alternatives.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct action and resource: submission (scan_url, scan_and_wait), result retrieval (get_scan_result, get_page_dom, get_screenshot_url), and searching by different pivots (domain, IP, ASN, hash, or generic query). Even the two scan tools are clearly differentiated by sync/async behavior, and the description explicitly points to scan_and_wait as the recommended default.

Naming Consistency4/5

The naming pattern is predominantly verb_noun: scan_url, get_scan_result, search_scans, list_available_countries, assess_indicator. The only inconsistency is 'server_capabilities' which lacks a verb prefix, breaking the otherwise consistent verb-first style; 'scan_and_wait' is a compound but still verb-led.

Tool Count5/5

With 14 tools, the server is well within the optimal 3-15 range. Every tool serves a distinct need for the urlscan.io use case: submitting, retrieving, searching, and managing quota/capabilities. No tool feels redundant or extraneous given the breadth of the underlying API.

Completeness5/5

The tool surface covers the full scan lifecycle (submit, wait, retrieve result, DOM, screenshot), historical search across multiple pivot types, quota management, and even an aggregated indicator assessment. There are no obvious dead ends; the capabilities tool also helps diagnose configuration issues, making the set self-sufficient.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ScanMalware.com URL Scanner C
com.scanmalware.mcp
MCP server for ScanMalware.com URL scanning, malware detection, and analysis.
Security Web Scraping App Automation
1282
sentrysurface
io.github.sentrysurface
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
Security Penetration Testing
2
Urlhaus A
io.github.pipeworx-io
URLhaus MCP — wraps abuse.ch URLhaus malware URL database (free, no auth)
Security Web Scraping Monitoring
352
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2

Related MCP Servers

VirusTotal MCP Server
Security Monitoring Web Scraping
w0h1v
A
license
A
quality
D
maintenance
A MCP server for querying the VirusTotal API. This server provides tools for scanning URLs, analyzing file hashes, and retrieving IP address reports.
Updated 3 months ago (2026-05-24 03:00 UTC)
11
389
149
MIT
Cyberbro MCP Server
Security Search Research & Data
stanfrbd
A
license
A
quality
A
maintenance
An MCP server that extracts Indicators of Compromise (IoCs) from unstructured text and checks their reputation across multiple threat intelligence services. It enables real-time analysis of IPs, domains, hashes, and URLs, providing enriched context for security workflows within LLMs.
Updated a month ago (2026-08-04 14:15 UTC)
5
19
MIT
virustotal-mcp-server
Security
barvhaim
F
license
A
quality
D
maintenance
MCP server for security analysis using VirusTotal API, enabling AI assistants to analyze URLs, files, IP addresses, and domains with automatic relationship fetching.
Updated a year ago (2025-08-25 16:18 UTC)
8
1
threatintel-mcp
Security Autonomous Agents
ChristianPresley
A
license
Not graded
quality
C
maintenance
An MCP server wrapping urlscan.io and VirusTotal APIs to enable AI agents to pivot on threat indicators during investigations, with compact structured output and defanged results.
Updated 2 months ago (2026-07-06 18:41 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/blackhole8080-darkmatter/urlscan-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server