crypto-link-check

Overview Schema Source Related Servers Discussions Admin

Check a crypto link for phishing

check_crypto_link

Read-onlyIdempotent

Check a URL or domain offline for crypto phishing signs, lookalike characters, typosquats, punycode and bait words before opening wallet, exchange or dapp links.

Instructions

Checks one URL or domain for signs of crypto phishing and tells you whether it belongs to a known wallet, exchange or dapp. Use it before an agent or user opens a link to connect a wallet, sign a message or approve a token, for example a link from an email, DM, ad, search result or support chat. It runs locally and offline. It makes no network request, does not visit the page, and does not ask for keys. It compares the hostname with a hand-curated list of official domains for about 60 brands and flags lookalike characters (0/o, rn/m, Cyrillic), typosquats, punycode, free hosting and bait words such as 'claim', 'airdrop' or 'sync'. Returns: verdict (official = on the official list; no_red_flags = nothing found, which is not proof of safety; caution = one warning, such as the brand name on a different TLD; suspicious = two or more warnings; dangerous = impersonation or lookalike), the parsed host and its Unicode form, the official brand it matches or the brand it seems to imitate, and a list of findings. Each finding has a level, code and message. It does not check domain age, DNS, redirects or page content. For those, see full_report_info (a paid hosted check). Unknown brands are not covered.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "check_crypto_link"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	The link to check: a full URL (https://phantom.app/download) or a bare domain (phantom.app). http(s) only; a missing scheme is treated as https. Public domain names only (no IP addresses or localhost). The hostname and the http/https scheme are judged; the path and query are not analyzed.

Output Schema

Name	Required	Description
`url`	Yes	normalized URL
`host`	Yes	hostname as ASCII/punycode
`input`	Yes
`verdict`	Yes
`findings`	Yes
`full_report`	Yes	URL of the paid hosted check for this link
`host_unicode`	Yes	hostname as it displays to users
`official_brand`	Yes	brand whose official list contains this domain, else null
`registrable_domain`	Yes
`impersonation_suspect`	Yes	brand this domain seems to imitate, else null
`full_report_price_usdc`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.1.0Oct 31, 2026

changedInput schema / properties / url / description

Previous value: -"URL or bare domain"New value: +"The link to check: a full URL (https://phantom.app/download) or a bare domain (phantom.app). http(s) only; a missing scheme is treated as https. Public domain names only (no IP addresses or localhost). The hostname and the http/https scheme are judged; the path and query are not analyzed."

addedInput schema / properties / url / maxLength
```
Added value: +2048
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "findings": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "code": {
+            "type": "string"
+          },
+          "level": {
+            "enum": [
+              "info",
+              "warn",
+              "danger"
+            ],
+            "type": "string"
+          },
+          "message": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "level",
+          "code",
+          "message"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "full_report": {
+      "description": "URL of the paid hosted check for this link",
+      "type": "string"
+    },
+    "full_report_price_usdc": {
+      "type": "number"
+    },
+    "host": {
+      "description": "hostname as ASCII/punycode",
+      "type": "string"
+    },
+    "host_unicode": {
+      "description": "hostname as it displays to users",
+      "type": "string"
+    },
+    "impersonation_suspect": {
+      "description": "brand this domain seems to imitate, else null",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "input": {
+      "type": "string"
+    },
+    "official_brand": {
+      "description": "brand whose official list contains this domain, else null",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "registrable_domain": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "url": {
+      "description": "normalized URL",
+      "type": "string"
+    },
+    "verdict": {
+      "enum": [
+        "official",
+        "no_red_flags",
+        "caution",
+        "suspicious",
+        "dangerous"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "input",
+    "url",
+    "host",
+    "host_unicode",
+    "registrable_domain",
+    "official_brand",
+    "impersonation_suspect",
+    "verdict",
+    "findings",
+    "full_report",
+    "full_report_price_usdc"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld=false, but the description adds substantive context they cannot: it runs locally and offline, makes no network request, does not visit the page, and never asks for keys. It also discloses the detection surface (lookalike characters, typosquats, punycode, free hosting, bait words) and explicitly lists what it does NOT check (domain age, DNS, redirects, page content), which is exactly the kind of limit an agent needs.

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?

Front-loaded with the core action, then usage trigger, then behavioral guarantees, then verdict semantics and limitations. Despite its length, every sentence carries decision-relevant information (verdict ladder, brand coverage size, exclusions) rather than restating the name or schema.

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?

Even though an output schema exists, the description adds the interpretive layer an agent needs: the five verdict levels explained, the caveat that 'no_red_flags' is not proof of safety, and the coverage gap for unknown brands and ~60 curatable brands. Nothing material about invocation risk or result interpretation is left implicit.

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

Parameters3/5

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

Schema description coverage is 100% and the parameter doc already covers full URL vs bare domain, scheme handling, and that only hostname/scheme are judged. The description only echoes 'one URL or domain' without adding format or constraint detail, so this is the baseline case where the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (checks one URL or domain for crypto phishing) and immediately adds the differentiating capability: telling whether it belongs to a known wallet, exchange or dapp. The sibling full_report_info is named later, so an agent can separate the two tools without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('use it before an agent or user opens a link to connect a wallet, sign a message or approve a token') plus concrete link sources (email, DM, ad, search result, support chat). It also names the alternative and its condition: 'For those, see full_report_info (a paid hosted check).'

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

Deploy Server