Skip to main content
Glama
dnsdoctor

DNS Doctor

by dnsdoctor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

get_alerts

Read-onlyIdempotent

Read the complete monitoring alert log for your domains to see every change or flag, even those omitted from digest emails. Filter by domain or type and page back through older alerts without missing a row.

Instructions

Use this when a signed-in operator asks what changed on a monitored domain, or what the monitoring has flagged. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.1

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already declare readOnly, idempotent, non-destructive, and the description adds substantial behavioral detail beyond them: API token requirement, row shape with delivery_class semantics, the pagination trap where advancing `since` before paging can drop rows, the inclusive `since` floor causing duplicate rows, and the explicit design decision to avoid ack/delete. This gives the agent a rich, accurate model of tool behavior.

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?

The description is long, but nearly every sentence carries operational value: usage trigger, row fields, delivery_class meaning, pagination warnings, inclusive-since behavior, and the read-only rationale. It is front-loaded with the when-to-use statement. It could be slightly tightened, but the length is justified by the pagination and de-duplication pitfalls.

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 read-only list/pagination tool with no output schema, the description covers everything an agent needs: when to call it, required auth, row field meanings, complete-vs-digest semantics, pagination mechanics, duplicate-row behavior, and what actions the agent should not take. There is no structural gap for a safe and correct invocation.

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

Parameters4/5

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

The schema already describes all five parameters with 100% coverage, so the baseline is 3. The description adds meaningful operational context beyond the schema: the critical ordering of `before` vs `since`, the need to de-duplicate on id, the 'unknown value is rejected' behavior on type, and the domain-ownership restriction. This elevates it above baseline.

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 specific use case — a signed-in operator asking what changed on a monitored domain or what monitoring flagged — and names the resource ('monitoring alert log') and ordering ('newest first'). It clearly distinguishes this from the domain-configuration and DMARC siblings by focusing on the alert log for monitored domains.

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 explicitly states when to use the tool: when a signed-in operator asks what changed or what monitoring flagged. It also gives behavioral guardrails ('there is no ack and no delete here... let them clear it'). It does not name sibling tools as alternatives, but the trigger conditions are specific enough that an agent can select it without confusion.

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