secureIT Sicherheits-Checks

Spoofing-Check anfordern (Freigabe durch Empfänger nötig)

spoofing_check_anfordern

Fordert einen CEO-Fraud-/Absenderfälschungs-Test an. WICHTIG: Dieses Werkzeug versendet noch KEINE gefälschte Mail. Es schickt lediglich eine Bestätigungsmail an den Empfänger; erst dessen eigener Klick löst den Test aus. Regeln: Empfänger- und gefälschte Absenderadresse müssen dieselbe Domain haben (nur die eigene Domain ist testbar), pro Domain ist ein ausführbarer Test je Stunde möglich, und der Mailinhalt ist fest vorgegeben (die Auflösung des Tests) — er kann nicht frei gestaltet werden. Fragen Sie den Nutzer vorher ausdrücklich um Zustimmung.

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": {
      "email": "<email>",
      "spoof_name": "<spoof_name>",
      "spoof_email": "<spoof_email>"
    },
    "name": "spoofing_check_anfordern"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	Adresse des Empfängers — muss dem Nutzer selbst gehören. Nur hierhin geht die Testmail.
`spoof_name`	Yes	Angezeigter Name des angeblichen Absenders, z. B. "Sabine Chefin".
`spoof_email`	Yes	Zu fälschende Absenderadresse — MUSS dieselbe Domain wie "email" haben.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description bears the full burden and does so well: it discloses the actual side effect (a confirmation mail is sent; the test only fires on the recipient's click), the rate limit, the fixed and non-configurable mail content, and a required consent step. These are exactly the behavioral traits an agent needs before invoking an outbound-email tool.

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 purpose and the 'WICHTIG' warning, then a compact rule list; each sentence carries a distinct constraint. Slightly long relative to the three-parameter schema, and the domain rule partially duplicates the schema text.

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 side-effecting tool with no annotations and no output schema, the description covers preconditions, side effects, rate limits, and consent thoroughly. The one remaining gap is what the call returns on success (token/id or confirmation), which the agent must infer.

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%, so all three parameters are already documented, including the domain-match rule on spoof_email and the 'must belong to the user' note on email. The description restates the same domain constraint without adding syntax, format, or edge-case detail, so the 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?

States a specific verb+resource ('Fordert einen CEO-Fraud-/Absenderfälschungs-Test an') and immediately clarifies the scope boundary that matters most: it does not yet send a spoofed mail, only a confirmation mail to the recipient. This clearly separates it from spoofing_check_status and from phishing_selbsttest_anfordern.

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 explicit preconditions and exclusions: recipient and spoofed sender must share the same domain, only one executable test per domain per hour, and the user must be asked for explicit consent first. It never names the sibling tool (spoofing_check_status) for retrieving the outcome, so routing guidance is strong but not complete.

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

All secureIT Sicherheits-Checks 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?