Straelo Relay

Email Suitability Decision

email_suitability_decision

Read-only

Evaluate whether an email address is suitable for a specified use case using syntax, MX, SPF, DMARC, disposable-domain, and role-account signals. Decision for observed evidence; external DNS evidence may change between calls. Returns an ALLOW, REVIEW, or REJECT decision with deliverability score, risk level, confidence, checks, and reasons. Does not send email, probe the mailbox via SMTP, verify that the mailbox exists or is owned by a specific person, or guarantee delivery. Read-only DNS lookups may affect latency or availability; no tool-specific rate limit. USE WHEN: an agent needs to decide whether an email address is suitable for outbound sales, account signup, transactional email, CRM import, lead qualification, or another supported use case. DO NOT USE WHEN: the agent needs domain-level risk and trust assessment or proof that a mailbox exists. USE domain_risk_trust_decision FOR: domain-level risk and trust assessment.

Input Schema

Name	Required	Description	Default
`email`	Yes	Email address for suitability decision.
`use_case`	No	Intended sending context; when provided, the decision accounts for context-specific risk. Omitted for a baseline decision without contextual adjustments.

Output Schema

Name	Required	Description
`email`	Yes	Validated email address (domain-lowercased).
`valid`	Yes	Backward-compatible validity summary based on deliverability score >= 60. Does not prove mailbox existence or delivery.
`checks`	Yes	Per-signal check results keyed by check name: syntax, domain, mx, spf, dmarc, disposable, role_account. Each value is a machine-readable result string (e.g. 'syntax:valid', 'mx:found', 'spf:pass', 'disposable:no'). Partial when a DNS lookup is unavailable.
`domain`	Yes	Lowercased domain part.
`reasons`	Yes	Machine-readable reason codes explaining the decision and corresponding to observed checks.
`decision`	Yes	Context-aware suitability decision for the given use case.
`mx_found`	No	Backward-compatible MX result; null means lookup unavailable.
`use_case`	No	The validated use case echoed from the input; null when omitted. Affects contextual decision adjustments such as role-account tolerance and SPF/DMARC weighting.
`confidence`	Yes	Confidence in the decision from 0 to 100.
`risk_level`	Yes	Risk level derived from observed signals.
`deliverability_score`	Yes	Deliverability score from 0 to 100.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 2, 2026

changedInput schema / properties / use_case / description

Previous value: -"Intended sending context; when provided, the decision accounts for context-specific risk."New value: +"Intended sending context; when provided, the decision accounts for context-specific risk. Omitted for a baseline decision without contextual adjustments."

addedOutput schema / properties / checks / description

Added value: +"Per-signal check results keyed by check name: syntax, domain, mx, spf, dmarc, disposable, role_account. Each value is a machine-readable result string (e.g. 'syntax:valid', 'mx:found', 'spf:pass', 'disposable:no'). Partial when a DNS lookup is unavailable."

addedOutput schema / properties / reasons / description

Added value: +"Machine-readable reason codes explaining the decision and corresponding to observed checks."

addedOutput schema / properties / use_case / description

Added value: +"The validated use case echoed from the input; null when omitted. Affects contextual decision adjustments such as role-account tolerance and SPF/DMARC weighting."

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only/non-destructive/open-world, and the description adds substantial context beyond them: no SMTP probing, no mailbox-existence proof, no delivery guarantee, DNS evidence drift between calls (explaining the non-idempotent hint), latency/availability impact, and no tool-specific rate limit.

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-loads mechanics and return shape before the bolded routing headers, and each block is scannable. Slight redundancy between the negative-capability sentence and the DO NOT USE WHEN clause (mailbox existence is stated twice) keeps it from 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 two-parameter read-only decision tool with an output schema, the description covers scope, exclusions, return structure, operational caveats, and sibling routing. An agent has everything needed to select and call it correctly.

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% and the use_case enum plus its default-null semantics are already documented in the schema, so the description adds nothing about parameters beyond restating 'specified use case'. 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?

First sentence states a specific verb+resource (evaluate an email address's suitability) plus the exact signal set used (syntax, MX, SPF, DMARC, disposable-domain, role-account) and the decision output (ALLOW/REVIEW/REJECT). It explicitly separates itself from domain_risk_trust_decision, the nearest sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit USE WHEN list with concrete scenarios (outbound sales, signup, transactional, CRM import, lead qualification), a DO NOT USE WHEN clause covering domain-level assessment and mailbox proof, and names the alternative tool to use instead.

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

All Straelo Relay tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?