Psychevus email security tools

Payment-change check

check_payment_change_request

Read-onlyIdempotent

Weigh an email asking to change a supplier's (vendor's) bank details, one of the costliest forms of business email compromise. Compares the sender (and Reply-To) with the supplier's real domain for lookalike tricks (other endings, look-alike or other-alphabet characters, typos, added words, the supplier's name in front of another domain), reads the sender domain's registration age and the supplier's DMARC policy, and uses the message's DMARC result when given (reported by the caller, not verifiable here). Returns a verdict (stop, caution or verify), the reasons with the source of each (public-records, comparison, reported or advice), and the steps to take. A supplier's DMARC policy is never taken as proof that a particular message is genuine. Never declares a request safe: the last step is always a call to a number already on file. Verdicts: stop = warning signs, don't change the details; caution = nothing proves it's the supplier; verify = no warning signs found, which is NOT verification: confirm by phone on a number you already had before paying. Pass addresses and domains only, never the message.

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": {
      "supplier": "<supplier>"
    },
    "name": "check_payment_change_request"
  }
}

Input Schema

Name	Required	Description
`dmarc`	No	The DMARC result for the sender from the topmost Authentication-Results header (the one the recipient's own mail server added), if known. It is reported, not verified: never pass a value from lower, sender-written headers.
`sender`	No	The From address (or domain) of the email asking for the change.
`account`	No	The new bank account (IBAN or account number), if known: compared with the supplier's published payment-policy.txt fingerprints. Never stored.
`message`	No	Optional: the full raw message (headers and body, as in Gmail's Show original), up to 1 MB. Its DKIM signatures are then verified here against the keys the signing domain publishes, which is stronger evidence than a dmarc value. Processed in memory, never stored.
`replyTo`	No	The Reply-To address, if different from the sender.
`supplier`	Yes	The supplier's real domain or usual email address, from records (not from the new email).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses that the DMARC value is caller-reported and unverifiable, that a supplier's DMARC policy never proves a message genuine, and that the tool never returns a 'safe' verdict. That is meaningful epistemic context for an agent consuming the result, though the return shape (reasons with sources, steps) is described only at a high level.

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?

Purpose and inputs are front-loaded and every paragraph is topically coherent, but the text is roughly 200 words and repeats the same safety point twice ('never taken as proof that a particular message is genuine' and 'Never declares a request safe', plus the phone-callback caveat restated inside the verify verdict). Tighter consolidation would keep the signal without the echo.

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?

With no output schema, the description carries the return-value burden and does so: verdict, reasons with source attribution, and recommended steps. The only substantive gap is the internal inconsistency over whether raw message content may be submitted, which matters because that parameter changes the strength of the evidence.

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

Parameters2/5

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

Schema coverage is 100%, so the baseline would be 3, but the closing instruction 'Pass addresses and domains only, never the message' directly contradicts the schema's optional `message` parameter, which is documented as enabling local DKIM verification and being 'stronger evidence than a dmarc value.' An agent reading both will be unsure whether to supply the raw message, so the description subtracts clarity rather than adding it.

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?

Opens with a specific verb and resource: weigh an email asking to change a supplier's bank details, framed as BEC. It names the concrete checks performed (sender/Reply-To vs. real domain, domain registration age, DMARC policy) and the output (verdict plus reasons), which an agent can distinguish from generic DNS/email-header siblings without opening the schema.

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?

It states the triggering situation (a supplier bank-detail change request) and gives explicit decision rules for the output: stop = don't change, caution = nothing proves it, verify = no warning signs but still confirm by phone on a number already on file. It does not name sibling tools or say when to prefer check_email_domain or analyze_email_headers instead, so routing is left to inference.

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

All Psychevus email security tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?