Check whether a website is trustworthy: trust score, verdict, red flags and a citable report.
Scored across 2 tools
The two tools target entirely different things: one performs a per-website trust lookup, the other lists published research articles. There is no plausible scenario where an agent could confuse checking a domain with browsing an editorial research index.
Both tools follow the same snake_case verb_noun convention (check_website, list_research), with a consistent, predictable structure. No mixed casing or conflicting verb styles.
Two tools is thin for a server, though the domain (trust-report lookup plus a research feed) is narrow enough that a small surface is defensible. It lands right at the borderline where each tool clearly earns its place but the set feels minimal.
The core lookup and research listing are covered, but there are notable gaps: no way to fetch a specific research entry or its dataset directly, no bulk/batch domain check, and no explicit retrieval of the full report beyond a URL reference. Agents can work around these via the returned links, but the surface isn't fully fleshed out.
Look up verified.fyi's independent trust report for a website: a 0-100 trust score, a verdict and a plain-English summary, drawn from automated checks (domain age, TLS, DNS, Google Web Risk, VirusTotal, blocklists, reviews, archive history, page content), with a link to the full report that lists every check. Use it before visiting, buying from, signing up to, or entering personal or payment details on an unfamiliar site, or when someone asks whether a site, online shop, link or sender's domain is legitimate, safe or a scam. Accepts a bare domain or any URL. Known sites return instantly. A site never checked before is scanned on demand, which usually takes 20-60 seconds; if the scan isn't finished within about 25 seconds the result has status "generating" and retry_after_seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| url_or_domain | Yes | The website to check: a bare domain such as example.com, or any URL on it. Only the hostname is assessed. |
| Name | Required | Description |
|---|---|---|
| score | No | Trust score from 0 (dangerous) to 100 (trusted). Omitted for Inactive sites and service endpoints. |
| domain | Yes | The hostname that was checked. |
| status | Yes | complete: the report is included. generating: a first scan is running, call again after retry_after_seconds. rate_limited: no report exists and new scans are paused, retry after retry_after_seconds or open report_url in a browser. failed: the scan could not complete. |
| summary | No | Plain-English assessment of the site. |
| verdict | No | Trusted, Mostly safe, Use caution, Suspicious, Dangerous, Inactive (site unreachable), or Service endpoint (a backend address of parent_domain, not a website). |
| checked_at | No | When the report was generated. Reports are refreshed at most every 7 days. |
| report_url | Yes | The full report on verified.fyi, listing every check behind the verdict. |
| attribution | Yes | Citation line for this data. |
| parent_domain | No | For a service endpoint, the established domain it belongs to. Check that domain for a trust verdict. |
| retry_after_seconds | No | For generating and rate_limited: seconds to wait before calling again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld), the description discloses the real behavioral traits: cached sites return instantly, uncached sites trigger an on-demand scan of 20-60 seconds, and after ~25 seconds the result may come back with status "generating" plus retry_after_seconds. That latency and partial-result behavior is exactly what an agent needs to plan around, and the annotations don't carry it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and the payload come first, the usage triggers follow, and the latency caveat comes last. The middle sentence is long and list-heavy, but each clause, including the list of underlying checks, earns its place by helping the agent judge relevance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needn't be explained, yet the description still flags the "generating" status and retry_after_seconds so the agent isn't blindsided. With latency, input format and scope all covered, nothing needed in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented in the schema, including the bare-domain-or-URL form and the fact that only the hostname is assessed. The description restates "Accepts a bare domain or any URL" rather than adding new meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ("Look up") and resource ("verified.fyi's independent trust report for a website"), and it spells out the payload: a 0-100 trust score, verdict, summary and full-report link. This makes it unmistakable from the only sibling, list_research, which does something unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete trigger conditions: before visiting, buying, signing up, entering payment details, or when someone asks whether a site, shop, link or sender's domain is legitimate. It gives no explicit when-not or named alternative, but the use cases are stated clearly enough that an agent can tell when to reach for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List verified.fyi's published research: original data stories built from its dataset of website trust reports, such as how a domain's age relates to scam risk. Each entry has the headline statistic, a short description, the publication date, and links to the story and its JSON dataset. Useful when someone asks for statistics or trends about scam, phishing or fraudulent websites, or wants citable data on online safety.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| stories | Yes | |
| attribution | Yes | Citation line for this data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful framing about the data's provenance (built from website trust reports) but says nothing about result volume, ordering, or freshness beyond the per-entry publication date.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, then the use case. The clause "original data stories built from its dataset of website trust reports" is somewhat padded but still carries relevance information for judging whether results fit the question.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description's recap of entry fields is redundant but harmless, and safety is fully covered by annotations. For a zero-parameter list tool this is nearly complete; only the absence of any note on list size or ordering keeps it short of full marks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies an unfiltered full listing rather than suggesting any hidden inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List verified.fyi's published research") and characterizes what each entry is (data stories from website trust reports). The contrast with the only sibling, check_website, is left implicit — an agent must infer that this tool enumerates published studies rather than evaluating a single domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear use condition: "Useful when someone asks for statistics or trends about scam, phishing or fraudulent websites, or wants citable data on online safety." It does not state when-not to use it or explicitly route the agent to check_website for single-domain lookups, so no exclusions are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_websitelist_researchThe website checker for AI agents. One call: verdict, score out of 100, fix list.
Scores any public website on how usable it is by AI agents, with per-check evidence.
Scan a public website for AI agent readiness: 60 checks, a score, and the evidence for each.
Score merchant domain, https URL, or 0x wallet trust before an agent pays. Does not send payments.
Add one secure layer between your agents and this server.