Skip to main content
Glama
hail-hq

hail

Official

Get email stats

get_email_stats
Read-onlyIdempotent

Account-level email deliverability stats (counts, rates, time series).

Instructions

Account-level email deliverability stats (counts, rates, time series).

    Aggregates across your whole organization's outbound mail over a
    window — use this for "how's deliverability doing" rather than
    one message's history (``get_email_events`` covers that).

    ``from_`` / ``to`` are ISO 8601 timestamps (defaults: last 7 days
    ending now). ``bucket`` is ``"day"`` (default) or ``"hour"`` —
    ``"hour"`` is limited to an 8-day span; any range is capped at 92
    days.

    Returns ``{"from": ..., "to": ..., "bucket": ..., "totals": {...},
    "rates": {...}, "series": [...]}`` — ``totals``/each ``series``
    bucket carry counts (sent, delivered, bounced, opened, ...) and
    ``rates`` carries derived ratios (delivery, bounce, open, click),
    each ``None`` when ``totals.sent`` is 0. Open and click numbers
    only count HTML emails. Plain-text-only emails are never tracked
    for opens or clicks, so they lower those rates. On failure returns
    ``{"error": "<message>"}`` instead.
    

Input Schema

NameRequiredDescriptionDefault
toNo
from_No
bucketNoday

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.29.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: default time window (last 7 days ending now), bucket span limits, the exact return shape, None-valued rates when totals.sent is 0, the caveat that plain-text-only emails are never tracked for opens/clicks, and the error envelope. That is exactly the behavioral detail an agent needs to interpret results correctly.

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?

Front-loaded with purpose and the sibling comparison, then parameters, then return shape — a logical order with little waste. The return-shape paragraph is dense and somewhat long, though each clause (None rates, HTML-only tracking) carries real behavioral information.

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?

Despite an output schema being present, the description rounds out the picture with rate-nulling semantics, tracking limitations for plain-text mail, and the error format. Combined with the safety annotations, an agent has everything needed to call this and interpret the result.

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?

Schema description coverage is 0%, so the description carries the full burden and does: from_/to are ISO 8601 timestamps with documented defaults, and bucket is named with its allowed values ("day" default, "hour") plus the 8-day restriction on hourly bucketing. No parameter is left ambiguous.

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?

States a specific verb+resource (account-level email deliverability stats) and immediately scopes it as an aggregate over the whole organization's outbound mail, naming the sibling get_email_events as the per-message counterpart. An agent can distinguish it from list_emails, get_email, and get_email_events without opening any schema.

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?

Explicitly routes the agent: use this for "how's deliverability doing" rather than one message's history, with get_email_events named as the alternative. It also gives concrete constraints that decide between parameter choices (hour bucket limited to 8 days, any range capped at 92 days).

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