Skip to main content
Glama

List notifications

list_notifications
Read-only

Read the organization's notification feed, newest first: what finished, what broke, and what changed since you last looked. Categories include audit_complete, issues_detected, audit_failed, broken_links, schedule_paused. Use this to catch up at the start of a session ("did last night's scheduled audit run?", "what failed?") instead of polling every website. Each entry carries the category, the human-readable title and body, a data payload with the ids involved (website_id, run_id, report_id), and whether a human has read it in the dashboard. Filter with category, or unread_only to see just what nobody has looked at yet. Paginated with limit/offset, or poll for new events: every response carries next_cursor, and passing it back as after returns only notifications created since, oldest first (offset is ignored). Read-only: this never marks anything read.

Input Schema

NameRequiredDescriptionDefault
afterNoOpaque cursor from a previous response's next_cursor. Returns only newer notifications, oldest first.
limitNoMax notifications to return (default 20, max 100).
offsetNoRows to skip (default 0).
categoryNoRestrict to these categories, e.g. ["audit_failed"]. Omit for every category.
unread_onlyNoOnly notifications no one has read in the dashboard yet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +{}
  2. Changed4 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / after
      Added value: +{
      +  "description": "Opaque cursor from a previous response's next_cursor. Returns only newer notifications, oldest first.",
      +  "maxLength": 512,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / offset / maximum
      Added value: +9007199254740991
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/destructiveHint, but the description adds a genuinely non-obvious trait: reading 'never marks anything read'. It also discloses ordering flip under `after` (oldest first) and that offset is ignored in that mode. Return-shape details (payload ids, read state, next_cursor) shade into completeness rather than 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?

Dense but front-loaded: what it is, then why/when, then entry shape, then filters, then pagination. Every sentence carries information, though the enumeration of categories and the parenthetical example questions push it slightly past minimal.

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?

With no output schema, the description covers what an agent needs: entry contents (category, title, body, payload ids, read state), pagination contract, and next_cursor round-trip for polling. Nothing material is left to guess for a zero-required-param read tool.

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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema doesn't: the interaction between `after` and `offset` ('offset is ignored'), that `after` reverses ordering to oldest-first, and how `category`/`unread_only` combine. That is real added semantics beyond the field docs.

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 and resource ('Read the organization's notification feed') plus ordering and scope ('newest first'), then enumerates the concrete categories (audit_complete, issues_detected, audit_failed, broken_links, schedule_paused). An agent can tell this apart from list_issues or list_audits 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?

Gives an explicit when-to-use with example questions ('did last night's scheduled audit run?', 'what failed?') and names the alternative it replaces ('instead of polling every website'). The unread_only filter is framed by purpose ('just what nobody has looked at yet').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.