Send anything. Get the truth — REAL, SUSPICIOUS or LIKELY SCAM verdicts on messages and links.
Scored across 3 tools
check_message (arbitrary text), check_url (one link), and screen_urls (batch of up to 25 links) are clearly separated by input type and cardinality. The only real overlap is check_url vs. screen_urls, since a single link can also be sent through the batch tool, but the descriptions make the single-vs-bulk distinction explicit.
All three names follow a snake_case verb_noun pattern (check_message, check_url, screen_urls), which is predictable and readable. The verb shifts from 'check' to 'screen' for the batch tool, a minor deviation that is semantically motivated but slightly breaks the uniform prefix.
Three tools is on the lean side but well-scoped: text, single URL, and bulk URL cover the natural input shapes for a verdict service. Nothing feels redundant, though a very narrow surface leaves little room for edge-case operations.
The core lifecycle — submit content, get a verdict, checks, score, certificate, and share link — is covered for both text and links, with bulk screening for URLs. Gaps exist: there is no batch equivalent for messages and no tool to retrieve or verify a previously issued verdict certificate/link.
Paste any suspicious text — a message, email, marketplace listing, job offer, investment pitch or link — and get a plain verdict (REAL / SUSPICIOUS / LIKELY SCAM) with every check shown, a warning score, what to do next, a signed verdict certificate, and a shareable verdict link. Content is processed, not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The full suspicious message or text to check (10–8000 characters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses the three possible verdicts, the accompanying artifacts (score, checks, certificate, shareable link), and the data-handling policy 'Content is processed, not stored.' It omits auth, rate/latency, and cost characteristics, but the core behavior is disclosed.
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?
A single dense sentence, front-loaded with the action and input types, followed by the payoff. The output enumeration is list-heavy but every item earns its place given there is no output schema. Slightly long but not wasteful.
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?
With no output schema, the description correctly does the work of describing returns (verdict, per-check detail, warning score, next steps, signed certificate, shareable link), and input format is covered by the schema. The one gap is the absence of routing guidance against the URL-checking siblings.
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?
One parameter with 100% schema coverage, so the schema already documents input format and the 10–8000 character bound. The description adds only the framing 'any suspicious text', which does not extend meaning beyond the schema. 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?
States a specific verb+resource ('check a suspicious message') and enumerates the accepted inputs (message, email, marketplace listing, job offer, investment pitch, link), which lets an agent distinguish it from the URL-oriented siblings. It stops short of stating the boundary explicitly, and listing 'link' as valid input creates minor ambiguity with check_url.
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?
'Paste any suspicious text' and the enumeration of content types imply when to use it, but there is no explicit when-not or routing statement naming check_url/screen_urls as alternatives for URL-only input. Usage is inferable rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one web link: it is followed safely server-side, tested for look-alike domains, domain age, sender rules, and the URLhaus known-bad list. Returns the same verdict, checks, certificate and share link as check_message.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full link to check, starting with http:// or https://. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses that the link is followed safely server-side (implying a non-destructive, sandboxed read), lists the concrete detection categories, and describes the return payload ('verdict, checks, certificate and share link'). It stops short of stating auth requirements, rate limits, or behavior on unreachable URLs.
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 core action, then the detection detail, then the return shape. Every clause carries information; there is no filler or restatement of the name.
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?
For a one-parameter tool with no annotations and no output schema, the description covers purpose, mechanics, and return contents, which is nearly everything an agent needs to invoke it correctly. Remaining gaps are minor: no statement about invalid input, network failure, or explicit read-only guarantee.
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 description coverage is 100% for the single 'url' parameter, which already documents that a full http:// or https:// link is required. The description adds only the 'one web link' cardinality hint, which is consistent with but not richer than the schema, so the baseline of 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?
States a specific verb and resource ('Check one web link') and enumerates exactly what is tested: look-alike domains, domain age, sender rules, and the URLhaus known-bad list. The word 'one' implicitly separates it from the plural sibling screen_urls, but neither sibling is named as an alternative, so sibling differentiation is only suggested rather than stated.
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?
Usage is implied by the title ('Check a suspicious link') and by the description's emphasis on inspecting a single link, but it never says when to reach for check_url versus screen_urls for a batch or check_message for a different resource type. No prerequisites, exclusions, or rate-limit guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
URL defense: screen up to 25 links in one call. Each link is followed safely server-side and gets a verdict (REAL / SUSPICIOUS / LIKELY SCAM), a warning score, and its top warning flags. Private/internal links are refused per item and invalid entries are reported per item — one bad entry never fails the batch. One screen counts as one free check.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | The links to screen (1–25), each starting with http:// or https://. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: server-side safe following, verdict taxonomy, per-item refusal of private/internal links, per-item invalid reporting, and batch atomicity ('one bad entry never fails the batch'). It omits auth/permission requirements and whether results are cached or live.
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?
Four tightly packed sentences, front-loaded with the core action and capacity limit, followed by return shape and error semantics. Every clause adds information an agent needs; nothing is boilerplate.
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?
There is no output schema, and the description compensates well by naming the verdict values, the warning score, and the warning flags returned per link, plus per-item failure behavior. Minor gaps remain around latency, caching, and any authentication needs.
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% with a single parameter, so the schema already documents the urls array, the 1-25 range, and the http:// or https:// requirement. The description largely restates the same constraints 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 states a concrete verb and resource ('screen up to 25 links in one call') and the batch limit implicitly separates it from the single-link sibling check_url. It never names check_url or check_message explicitly, so the differentiation is inferable rather than stated.
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?
Usage is implied by the batch framing ('up to 25 links in one call'), and the cost note ('one screen counts as one free check') hints at when bulk screening is worth it. There is no explicit when-to-use vs check_url guidance or any exclusion criteria.
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_messagecheck_urlscreen_urlsAI-powered scam and threat verification for phone numbers, URLs, texts, and emails.
AI-powered scam detection for suspicious texts, emails, and screenshots. US-focused.
Scan suspicious messages, URLs, and text for scams with AI. Free tier - no API key required.
Scam and phishing detection for AI agents: safe/warn/danger verdicts for URLs and messages.
Add one secure layer between your agents and this server.
