Skip to main content
Glama
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA

Verify Email Sending Domain

verify-email-domain

Trigger an immediate DNS check on a sending domain and return its verification result, so you can confirm records without waiting for the next scheduled check.

Instructions

Check a sending domain's DNS records now, instead of waiting for the periodic check, and return the result. A record published minutes ago can still read pending while DNS catches up: tell the user and try again later rather than calling in a loop.

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": {
      "id": "<id>"
    },
    "name": "verify-email-domain"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe domain id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), it discloses that a freshly published record can still read `pending` due to DNS propagation lag and prescribes the response: tell the user and retry later. That is genuine behavioral context an agent could not infer from structured fields. It does not explain the non-readonly/non-idempotent nature of the call, which is a small remaining gap.

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

Conciseness5/5

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

Two tight sentences, with the action and its timing rationale front-loaded and the misuse warning placed last. Every clause earns its place, and the backticked `pending` value is a precise, useful detail.

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 one-parameter tool with no output schema, the description covers the action, the timing motivation, and the key edge-case outcome (pending due to DNS lag). The only shortfall is that it does not sketch the return shape beyond 'the result', though no output schema exists to do that for it.

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 there is a single required `id` parameter fully documented as the domain id. The description adds no additional meaning about the parameter (e.g., where to obtain the id), so the high-coverage baseline of 3 applies.

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 uses a specific verb and resource ('Check a sending domain's DNS records') and separates the tool from the passive periodic check. It does not explicitly name the sibling read tool (get-email-domain), so the differentiation is contextual rather than stated.

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 clearly states when to use this tool (need an immediate check rather than waiting for the periodic one) and when not to hammer it ('try again later rather than calling in a loop'). It stops short of naming an explicit reading alternative, but the retry guidance prevents the main misuse pattern.

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

Deploy Server

Other Tools