Skip to main content
Glama

Check a Page Before Logging In or Paying

check_before_action
Read-onlyIdempotent

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

NameRequiredDescriptionDefault
urlYesAddress of the page (https://…)
pageNoOptional page structure, host names only
actionYesWhat is about to happen on the page
expectedBrandNoBrand the page is believed to belong to (e.g. 'PayPal', 'Shinhan Card'); a domain without that name is noted

Output Schema

NameRequiredDescriptionDefault
hostYesHost the address ended on (after redirects)
ageDaysNoDays since the domain was registered, when known
signalsYes
verdictYesdanger: 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)
receiptsNoSigned 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.
uncheckedYesWhat 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)
paymentProviderNoPayment provider recognised for the page or its card frame

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / unchecked / description
      Previous value: -"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' (not checked yet)"New value: +"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)"
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

With annotations already covering read-only/idempotent/open-world safety, the description adds substantial context: it is rate-limited, the structure is not stored, paths/queries/field values are not accepted, the return includes signals with sources plus a signed observation record, and it carefully defines verdict semantics including that no_signals is not a safety guarantee and 'unchecked' lists what was skipped.

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?

The core purpose is front-loaded in the first clause, and nearly every clause carries a specific, non-redundant fact (provider list, Korea/Japan rendering path, structural-omission rule). However, it is one very dense paragraph with heavy em-dash nesting and a long provider enumeration, which costs some readability for an agent parsing quickly.

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 complex, open-world, nested-schema tool with an output schema present, the description covers what the agent must know: the inputs' allowed shape and limits, the verdict vocabulary, what is and is not stored, and the signed-record return. Return-format detail is rightly delegated to the output schema.

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 3-baseline applies, but the description adds genuine meaning beyond field names: card fields outside a named list of payment providers are flagged, a fake card window inside a real shop is only detectable via this structure, and only host names may be reported (paths, queries, values excluded). It also notes the expectedBrand effect of noting domains lacking the brand name.

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?

The description opens with a precise verb+resource framing ('Check the page an agent is about to log in, pay, download from or submit to') and enumerates exactly what is examined: brand impersonation, domain age, prior flagging by DechoNet/licensed feeds, and rendered page behavior from Seoul/Tokyo. This composite, pre-action verdict framing is clearly distinguishable from single-signal siblings like phishing_link_check or lookalike_domains.

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?

Usage context is explicit — the tool is meant for the moment before login, payment, download, or submission, and it further specifies that callers may submit page structure for payments. It stops short of naming alternatives or stating when not to use it (e.g., vs. phishing_link_check for a link you are not about to act on).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources