Dechonet-MCP

Phishing / Smishing Link Check

phishing_link_check

Read-onlyIdempotent

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.

Changed1 schema field changedOct 15, 2026

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": {
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "tool": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "tool",
+      "id",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedOct 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."

AddedOct 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent safety, yet the description adds substantial non-obvious behavior: it reads landing-page HTML, may execute page scripts in isolated Chromium under a shared daily cap, explicitly does not click or submit forms, stores no message text, needs no API key, and is rate-limited. It also explains what each verdict does and does not mean (no_signals ≠ safe), which is high-value disclosure.

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-loaded with the core action and the when-to-use cue, and every clause is informative rather than filler. It is a dense single block that could be broken into shorter sentences, so not quite a 5.

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 single-input check tool with an output schema already present, the description still supplies the full behavioral picture: signal sources, verdict meanings, privacy handling, auth/rate constraints, and the isolated-browser caveat. Nothing an agent needs to invoke it 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?

There is one parameter with 100% schema description coverage, so the schema already documents the input, including the redaction advice and non-storage. The description restates 'paste the whole message or a single URL' and adds the 'up to 5 links' cap, but adds little semantic meaning beyond the schema, matching the baseline of 3.

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 (check/extract/follow/judge) and resource (links in a suspicious message) with exact scope, and the verdict taxonomy (danger, suspicious, unreachable, official, no_signals) makes it clearly distinct from siblings like lookalike_domains or report_page.

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?

Explicitly says 'Use this when a user asks whether a link or message is a scam,' giving a clear trigger condition. It does not name alternative sibling tools or state when not to use it, 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.

All Dechonet-MCP tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?