Dechonet MCP

Phishing / Smishing Link Check

phishing_link_check

Read-onlyIdempotent

Check suspicious text messages or emails for scam links before anyone taps them. Extract URLs, follow shorteners, and return per-link verdicts with reasons.

Instructions

Check the links in a suspicious text message (smishing) or e-mail before anyone taps them. Paste the whole message or a single URL: every link is extracted, followed through URL shorteners to its real destination, and judged on observable signals — domain age from RDAP, impersonation of Korean banks/couriers/telecoms/portals and global brands incl. AI services such as ChatGPT/Claude/Gemini (brand keyword, lookalike spelling, or the brand domain worn as a subdomain), ClickFix pages (a fake "verify you are human" check that has the visitor paste a command into Win+R/PowerShell), Android APK downloads, punycode, public phishing/malware feeds, and DechoNet's own impersonation tracking. Use this when a user asks whether a link or message is a scam. Verdicts: danger, suspicious, unreachable, official (lands on the brand's own domain), no_signals (no warning signs found; this is not a finding that the link is safe). Reads landing-page HTML; inconclusive links may also run page scripts in isolated Chromium under the shared daily cap. DechoNet does not click, enter values or submit forms. The message text is not stored; requires no API key; rate-limited. Returns per-link verdicts with reasons and a shareable report link.

Input Schema

Name	Required	Description	Default
`text`	Yes	The link(s) to check — a URL, or the message text with verification codes, passwords and personal details removed (any language). Only the links are used (up to 5); the text is not stored.

Output Schema

Name	Required	Description
`links`	Yes
`verdict`	Yes	danger \| suspicious \| unreachable \| official \| no_signals \| no_links
`receipts`	No	Signed observation receipts behind this result, one per lookup: when, from where and under which rules version DechoNet observed it. Each url shows the record and checks its Ed25519 signature.
`reportUrl`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.5.14Oct 15, 2026

changedInput schema / properties / text / description

Previous value: -"The suspicious message exactly as received (any language), or just the URL. Up to 5 links are checked."New value: +"The link(s) to check — a URL, or the message text with verification codes, passwords and personal details removed (any language). Only the links are used (up to 5); the text is not stored."

addedOutput schema / properties / receipts

Added value: +{
+  "description": "Signed observation receipts behind this result, one per lookup: when, from where and under which rules version DechoNet observed it. Each url shows the record and checks its Ed25519 signature.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "tool": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "tool",
+      "id",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Addedv1.3.1Oct 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: how links are resolved through shorteners, the exact signal set consulted (RDAP age, brand impersonation, ClickFix, APK, punycode, feeds), the verdict taxonomy including the important caveat that no_signals is not a safety assertion, the isolated-Chromium fallback under a shared daily cap, and the explicit statement that it does not click, enter values, or submit forms. It also discloses privacy (message not stored), no API key, and rate limiting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and the trigger condition, then the signal list and caveats. It is dense and long for a one-parameter tool, and the signal enumeration could be trimmed, but nearly every clause carries operational information an agent would otherwise lack.

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?

An output schema exists, so return values need not be explained, and the description still summarizes the verdict shape and shareable report link. Combined with the privacy, rate-limit, and no-side-effect disclosures, nothing needed to call this tool correctly is missing.

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 single parameter is already documented, including the up-to-5-link limit and the no-storage note. The description reinforces the paste-whole-message-vs-single-URL semantics but adds little the schema does not already state, so baseline 3 applies.

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?

Names a specific action and resource: extract, resolve, and judge links in a suspicious message/URL. It is clearly distinguishable from sibling lookups (dns_lookup, ssl_check, whois_lookup, lookalike_domains) because it deliberately composes those signals into a phishing verdict rather than exposing a single raw record.

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?

Gives an explicit trigger condition: 'Use this when a user asks whether a link or message is a scam.' It does not name a competing sibling or state when not to use it (e.g. when only a bare domain's DNS/TLS data is wanted instead), so routing guidance is clear but not exhaustive.

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