Skip to main content
Glama

dns-doctor

by dev.dnsdoctor

get_alerts

Read-onlyIdempotent

Read the monitoring alert log for the domains the caller's account monitors, newest first. Requires an API token. Each row carries id, domain, type, check, summary, a deterministic detail map, created_at, email_sent_at, acknowledged_at and delivery_class — a 'dashboard_only' row was deliberately kept out of the digest mail, so an agent watching only the inbox would never see it; this log is the complete picture. PAGE DOWN BEFORE ADVANCING since: next_before is non-null exactly when older rows remain, and a caller that ignores it, takes a full page and moves its watermark to the newest row it saw drops every row it did not receive. since is an INCLUSIVE floor, so rows repeat rather than go missing — de-duplicate on id. READ-ONLY by decision: there is no ack and no delete here, because acknowledging an alert is the human's own triage on their dashboard and an agent that acks on their behalf silences a row they have never seen. Report what the log says and let them clear it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoOptional alert-type filter, e.g. 'record_changed'. An unknown value is rejected rather than silently returning an empty page — omit it unless you know the exact type.
limitNoPage size, 1..100 (default 50). Page down with `before` before you advance `since`, or you will skip every row you did not receive.
sinceNoOptional ISO-8601 timestamp: return alerts created at or after it (INCLUSIVE). Poll by storing the newest created_at you have seen and passing it back — rows repeat rather than go missing, so de-duplicate on id.
beforeNoThe opaque cursor from a previous page's next_before, relayed verbatim to fetch the next older page. Never construct or edit one.
domainNoOptional filter to ONE of the account's verified monitored domains. Omit it for every domain the account monitors; an unowned or unknown name is refused as not found.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds rich behavioral context: it requires an API token, explains why the tool is read-only (to avoid silencing unread alerts), details the `dashboard_only` delivery_class nuance, and exposes pagination edge-case behavior (dropping rows when ignoring `next_before`). No contradictions with annotations.

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 longer than average but every sentence carries operational weight. It is front-loaded with the core purpose and scope, followed by field highlights, then high-stakes pagination warnings in caps, and finally the read-only rationale. No filler or redundancy.

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?

Given this is a data retrieval tool with a generic output schema (indicated by 'Has output schema: true'), the description covers all necessary contextual aspects: authentication, scope, field list, pagination behavior, exclusion semantics, and usage guardrails. It is complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds significant semantic value: it explains the inclusive `since` floor and de-duplication need, warns that `before` is an opaque cursor never to be constructed/edited, and notes that unknown `type` or `domain` values are rejected, not silently ignored. This goes well beyond the schema descriptions.

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 opens with a precise verb-resource-scope statement: "Read the monitoring alert log for the domains the caller's account monitors, newest first." This distinguishes it clearly from all sibling tools, which are about DNS/SPF/DMARC checks or report generation, not alert logs.

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?

It explicitly frames when this tool is appropriate ("agent watching only the inbox would never see it; this log is the complete picture") and when not to use it for actions ("there is no ack and no delete here"). It also gives crucial operational guidance on pagination ('PAGE DOWN BEFORE ADVANCING `since`') and the inclusive `since` semantics with de-duplication advice.

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

All dns-doctor toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct DNS or email authentication task. Despite multiple DMARC-related tools, their purposes are clearly differentiated: build_dmarc_upgrade upgrades policies, generate_dmarc_record creates new ones, validate_dmarc_record validates pasted records, and scan_domain vs get_report differentiate fresh vs cached scans.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., build_dmarc_upgrade, check_record, scan_domain). No mixing of naming conventions, making the set predictable and easy to navigate.

Tool Count5/5

With 11 tools, the server is well-scoped for a DNS/email authentication diagnostics tool. The number covers essential operations without being overwhelming or sparse.

Completeness4/5

The tool set covers core workflows: DMARC management (generate, validate, upgrade, parse reports), DNS checks (propagation, reverse DNS, SPF lookups), and DKIM selector checks. Minor gaps exist, such as the absence of SPF validation or DKIM signature verification, but the main diagnostic and monitoring use cases are supported.

Resources