Skip to main content
Glama

get_alerts

Read-onlyIdempotent

Retrieve the complete monitoring alert log for your domains, newest first. Filter by type, domain, or timestamp, and page through older entries with a cursor to see even dashboard-only alerts.

Instructions

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.
Behavior5/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false, but the description adds depth: it explains the deliberate read-only design ('acknowledging an alert is the human's own triage'), details the delivery_class semantics ('dashboard_only' rows excluded from digest mail), and the inclusive-since behavior that causes row repetition. This is valuable contextual information beyond the 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 dense but every sentence earns its place: purpose, paging rule, inclusive-since semantics, read-only rationale, and row field enumeration. It is front-loaded with the core action and progressively provides necessary detail without fluff 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 there is no output schema, the description compensates by naming all returned row fields (id, domain, type, check, summary, etc.) and explaining the delivery_class meaning. It covers authentication (API token), paging, filters, and behavioral constraints, making it complete for an agent to use 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 the schema already describes each parameter (100% coverage), the description adds critical operational meaning: `since` is an INCLUSIVE floor (so de-duplicate on id), `before` is an opaque cursor that must be relayed verbatim, and invalid `type`/`domain` values are rejected rather than silently ignored. This clarifies usage subtleties that raw schema descriptions omit.

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 'Read the monitoring alert log for the domains the caller's account monitors, newest first', which clearly states the action (read), resource (monitoring alert log), and scope (caller's domains, newest first). This distinguishes it from sibling tools focused on DNS/DMARC operations, making the purpose unmistakable.

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?

The description provides explicit procedural guidance: 'PAGE DOWN BEFORE ADVANCING `since`' and warns that ignoring it drops rows. It also states when not to use mutation-like operations ('there is no ack and no delete here') and clarifies the read-only intent. This goes beyond simple context to give definitive usage rules.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dnsdoctor/claude-plugin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server