Skip to main content
Glama
Sign In
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Email Sending Domain

get-email-domain
Read-onlyIdempotent

Retrieve a sending domain by ID with its DNS records and last-check statuses to confirm required verification and recommended deliverability records.

Instructions

Get one sending domain with the DNS records to publish and the status of each as of the last check. The domain is verified once every required record is; the other records are recommended for deliverability. To check the records again now, call verify-email-domain.

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": "get-email-domain"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe domain id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value the annotations cannot: the data is a cached snapshot ('as of the last check'), verification is derived from all `required` records, and non-required records are merely recommended. It stops short of describing error behavior for a bad or unknown id.

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 sentences, both earning their place: the first states what is returned, the second explains the verification model, and a closing clause routes to the refresh tool. Nothing is repeated from the title or schema.

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 burden of describing the response and does so concretely (records, per-record status, verified derivation), which is what an agent needs to interpret results. Missing only edge-case detail such as what happens when the id does not exist.

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?

The single parameter `id` is fully documented in the schema as 'The domain id.' with a UUID format and pattern, so coverage is complete. The description adds no syntax, sourcing, or lookup hints beyond what the schema already states. With 100% schema coverage, the baseline of 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 and resource ('Get one sending domain') and immediately scopes the payload: DNS records to publish plus each record's status as of the last check. An agent can distinguish this from list-email-domains and from the verify sibling without opening any 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?

Explicitly names the alternative for the refresh case: 'To check the records again now, call verify-email-domain.' That is a clear use-this-vs-that rule for the most likely confusion. It does not cover when to prefer this over list-email-domains, but the retrieval-by-id nature makes that largely self-evident.

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