dns-doctor

Get Monitoring Alerts

get_alerts

Read-onlyIdempotent

Use this when a signed-in operator asks what changed on a monitored domain, whether its website went down, or what the monitoring has flagged. Read the monitoring alert log for the domains the caller's account monitors, newest first, including website uptime incidents (site_down, site_partial, site_recovered, and site_blocked when the site's protection refuses our checks). 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

Name	Required	Description
`type`	No	Optional 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.
`limit`	No	Page size, 1..100 (default 50). Page down with `before` before you advance `since`, or you will skip every row you did not receive.
`since`	No	Optional 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.
`before`	No	The opaque cursor from a previous page's next_before, relayed verbatim to fetch the next older page. Never construct or edit one.
`domain`	No	Optional 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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedAug 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description consistently reinforces that with an explicit read-only decision and rationale. It adds crucial behavioral context beyond annotations: API-token requirement, inclusive `since`, de-duplication on id, pagination risk, and the meaning of `dashboard_only` rows.

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 front-loaded with the triggering use case and then moves into operational details. It is dense and purposeful, though listing every returned column is somewhat redundant given the output schema exists, and the pagination warning is verbose even though it is important.

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 an output schema and full parameter coverage, the description supplies everything else an agent needs: auth requirement, account/domain scope, pagination safety, de-duplication guidance, read-only boundary, and the significance of dashboard-only rows. Nothing essential for correct invocation is missing.

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?

Schema description coverage is 100%, so the schema already documents parameters well. The description still adds meaningful workflow semantics beyond the schema, especially that `next_before` must be paged through before advancing `since`, that `since` is inclusive, and that rows should be de-duplicated on id.

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: read the monitoring alert log for monitored domains, newest first, including uptime incidents. It clearly distinguishes this monitoring/log tool from the DNS and email-testing siblings by scope and returned data.

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 names the operator questions that should trigger this tool: what changed, whether a site went down, or what monitoring flagged. It also states a clear when-not boundary by explaining there is no ack or delete here because that is the human's triage action.

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

All dns-doctor 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.