Psychevus email security tools

DNS propagation watch

check_dns_propagation

Read-onlyIdempotent

After a DNS change, check whether four public resolvers (Cloudflare, Google, NextDNS, AdGuard) already return the new SPF, DMARC, DKIM, MTA-STS, TLS-RPT or BIMI record, and how long caches may keep the old one. Pass the value just published as expect to compare.

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": {
      "domain": "<domain>",
      "record": "<record>"
    },
    "name": "check_dns_propagation"
  }
}

Input Schema

Name	Required	Description
`domain`	Yes	A domain (example.com), website URL or email address on that domain.
`expect`	No	The value just published (or a fragment such as p=quarantine).
`record`	Yes	Which record to check.
`selector`	No	DKIM or BIMI selector, e.g. google or s1.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, open-world status and non-destructiveness, so the description does not need to repeat them. The description still adds real detail: it names the four resolvers queried, says results include how long caches may keep the old value, and explains that expect drives the comparison. It omits rate limits, privileges and whether results are reported per resolver.

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?

The description is two sentences, and the sentence telling the agent when to use the tool comes first. Every clause carries information: the resolvers checked, the record types, the cache caveat, and the expect comparison.

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 4-parameter, read-only diagnostic with a 100% schema description coverage and no output schema, the definition covers when to use it, what it queries and what the expect comparison means. It never describes the result shape, such as per-resolver verdicts, so one small gap remains.

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 the schema already defines domain, expect, record and selector, including the enum of record types and the DKIM/BIMI selector examples. The description's use of expect only restates the schema's 'value just published' wording and adds no syntax or format detail the schema lacks, which fits the baseline score of 3.

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?

The description states a specific verb and resource ('check whether four public resolvers ... already return the new SPF, DMARC, DKIM ... record') and limits scope to the post-change scenario, which separates it from the sibling tools check_email_domain and analyze_email_headers.

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?

'After a DNS change' tells the agent the triggering situation, and 'Pass the value just published as expect to compare' tells it how to invoke the tool. It never says what to use instead when no DNS change has happened, nor when to use check_email_domain, so it gets 4 rather than 5.

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?