Skip to main content
Glama
hail-hq

hail

Official

Get events

get_events
Read-onlyIdempotent

Page through events from across the org or one resource.

Instructions

Page through events from across the org or one resource.

    Pass ``id="<type>:<uuid>"`` to narrow to a single resource —
    supported types are ``call``, ``email``, and ``sms`` (e.g.
    ``id="sms:<uuid>"`` after ``send_sms``). When narrowed to a
    call, the response includes a ``call_status`` field reflecting
    the call's current state. Without ``id``, returns events from
    across the whole org. ``kind`` filters server-side by event kind
    (``state_change``, ``agent_turn``, ``user_turn``, ``tool_call``,
    ``error``, ...).

    This is **not** a streaming subscription — the call returns
    whatever events exist now plus a ``next_cursor`` if more pages
    remain. To follow a call to completion, loop: pass the previous
    response's ``next_cursor`` until ``next_cursor`` is null and,
    when narrowed to a call, ``call_status`` is one of
    ``completed``, ``failed``, ``busy``, ``no_answer``, ``canceled``
    (the terminal set).

    Example:
        get_events(id="call:0c2f...-...", limit=200)

    Returns ``{"items": [...], "next_cursor": <str|None>,
    "call_status": <str|None>}`` on success, or
    ``{"error": ...}`` on a malformed ``id`` or upstream failure.
    

Input Schema

NameRequiredDescriptionDefault
idNo
kindNo
limitNo
cursorNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.29.0

TDQS

A4.5/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 goes well beyond them: it discloses snapshot-plus-cursor semantics, the terminal `call_status` set that governs when polling may stop, and the `{"error": ...}` shape for malformed ids or upstream failures. This is exactly the extra context the annotations cannot convey.

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 the core purpose and the two modes, then the polling contract, then an example. Slightly long, and the final paragraph restating the return shape partially duplicates the output schema, but the prose is dense and each block serves navigation rather than filler.

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 4-param, 0-required paginated read tool with an output schema, nothing an agent needs is missing: resource scoping, filter values, cursor loop termination condition, and error behavior are all covered. Return field documentation is appropriately left to the output schema.

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 0%, so the description carries the full burden and largely does: `id` gets a format spec and enumerated type prefixes, `kind` gets a server-side filtering note plus sample values, and `cursor` is explained through the loop pattern. `limit` is only shown in an example (`limit=200`) with no default, maximum, or range stated, leaving one real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (page through) and resource (events) plus explicit scope: org-wide by default, or narrowed to one resource via an `id` of the form `<type>:<uuid>`. It does not name the potentially confusable sibling `get_email_events`, so an agent must infer the distinction from scope alone.

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 separates the two modes (with `id` = single resource, without `id` = whole org), names the supported narrowing types, and gives the alternative workflow for following a call: loop on `next_cursor` rather than expecting a stream. It explicitly rules out the streaming interpretation with 'This is **not** a streaming subscription'.

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