Dechonet MCP

Check a Page Before Logging In or Paying

check_before_action

Read-onlyIdempotent

Check a page before an AI agent logs in, pays, downloads, or submits. Detect brand impersonation, new domains, hidden instructions, and payment-frame mismatches, then return a verdict.

Instructions

Check the page an agent is about to log in, pay, download from or submit to: whether the address impersonates a brand, how new the domain is, whether DechoNet or a licensed feed has already flagged it, and — opened from Seoul (and Tokyo for Japan-targeted pages) as a phone — what the page turns into, including text it hides from people but an AI agent would read (instructions to ignore its rules, hand over secrets or keep the user out of it raise the answer to suspicious). For a payment, the caller can report the page structure as host names only (where forms submit, which origins frames come from, whether the card fields sit on the page itself or in a frame and that frame's origin): card fields outside a known payment provider (Stripe, PayPal, Braintree, Adyen, Square, Checkout.com, Toss Payments, KG Inicis, NHN KCP, NICE Payments, Naver Pay, Korean card issuers and banks) are reported as suspicious — a fake card window inside a real shop shows up only this way. Paths, queries, field values and page text are not accepted, and the structure is not stored. Verdicts: danger, suspicious, unreachable, official, no_signals. no_signals means none of the checks found a warning sign and is not a statement that the page is safe; 'unchecked' lists what was not looked at. Rate-limited. Returns signals with their source and a signed observation record (host and verdict only).

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Address of the page (https://…)
`page`	No	Optional page structure, host names only
`action`	Yes	What is about to happen on the page
`expectedBrand`	No	Brand the page is believed to belong to (e.g. 'PayPal', 'Shinhan Card'); a domain without that name is noted

Output Schema

TableJSON Schema

Name	Required	Description
`host`	Yes	Host the address ended on (after redirects)
`ageDays`	No	Days since the domain was registered, when known
`signals`	Yes
`verdict`	Yes	danger: evidence the page impersonates or attacks; suspicious: warning signs; unreachable: could not be read; official: the brand's own domain; no_signals: none of the checks found a warning sign — not a statement that the page is safe (see unchecked)
`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.
`unchecked`	Yes	What was not looked at: 'page_structure' (no structure sent for a login or payment), 'rendering' (the page was not opened in a browser), 'hidden_instructions' (so hidden text aimed at AI agents was not read)
`paymentProvider`	No	Payment provider recognised for the page or its card frame

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.5.14Oct 15, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With readOnlyHint/idempotent/destructive hints already covering safety, the description still adds a great deal: it is rate-limited, it enumerates the exact verdicts (danger, suspicious, unreachable, official, no_signals), it warns that no_signals is not a safety claim, it discloses that 'unchecked' lists what was not examined, and that output includes signals with sources plus a signed observation record. That is unusually rich disclosure and is consistent with the annotations.

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

Conciseness3/5

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

The opening clause is well front-loaded, but the body is a single sprawling paragraph dense with parentheticals and em-dashes (the full payment-provider list, the render caveats) that is hard to scan. Most content earns its place, but the structure does not aid rapid reading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool with nested objects, an enum action, and an output schema, the description covers the important caveats (rate limiting, verdict semantics, unchecked scope). Since an output schema exists it need not restate return shapes, and the main remaining gap is the absent routing against sibling phishing/impersonation tools.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains why the page structure matters (card fields outside a known payment provider list are reported suspicious, and this is the only way a fake card window inside a real shop surfaces), constrains the structure to host names only, and notes that expectedBrand causes a domain mismatch to be reported. This goes beyond the schema's field-level text.

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

Purpose4/5

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

The description names a specific verb (check) and a precise resource/trigger (the page an agent is about to log in, pay, download from or submit to), then enumerates exactly what is examined: brand impersonation, domain age, feed flags, headless-render behavior, and card-field placement. It is far more specific than a generic 'check page.' It does not, however, differentiate itself from potential siblings like phishing_link_check or impersonation_exposure, so it stops short of a 5.

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?

The usage trigger is explicit and front-loaded: call it before logging in, paying, downloading, or submitting. It also states input exclusions (paths, queries, field values and page text are not accepted, structure not stored), which is a useful 'when-not' for arguments. It never names an alternative sibling or explains when a different check would be preferable, so no 5.

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