Skip to main content
Glama

List Notifications

fizzy_get_notifications
Read-only

Fetch account notifications to identify unread items needing attention, including read/unread status, timestamps, and related cards. Page through older read notifications for history.

Instructions

Get notifications for the current user in an account. Returns notification content, read/unread status, timestamps, and related cards or comments. By default (page omitted) returns up to 100 unread notifications followed by the most recent page of already-read ones — this is what you want for 'what needs my attention'. Pages 2 and up contain ONLY older, already-read notifications; no unread notification ever appears there. To walk back through history, call with page=2, then 3, and so on until the array comes back empty. Page size is server-controlled and variable, so never derive counts or remaining history from the length of a page. Use fields='summary' to shrink the embedded card and creator objects down to their key identifying fields — typically several times smaller than the full payload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage of already-read notification history to fetch (1-based). Omit (or pass 1) for the default response: up to 100 unread notifications followed by the most recent page of read ones. Pages 2 and up contain ONLY older, already-read notifications - no unread ones ever appear there. Page size is server-controlled and variable, so never infer counts or how much history is left from how many items a page returns; walk with page=2, 3, ... until the array comes back empty.
fieldsNoResponse projection. 'full' (the default — used when this parameter is omitted) returns every field exactly as the API provides it, unchanged from prior behavior. 'summary' strips large, rarely-needed fields — full HTML/rich-text bodies and descriptions, duplicated plain-text/HTML pairs, and repeated embedded objects like the full creator or card — keeping only IDs, names, and short previews. Summary responses are typically 4x to over 100x smaller depending on the tool. Prefer 'summary' when scanning, searching, or listing many results; switch to 'full' (or a single-item fetch tool) once you need complete detail on a specific item.
account_slugYesThe account slug identifier (e.g., '123456' or '/123456'). This identifies which Fizzy account to operate on. Get available account slugs from fizzy_get_identity or fizzy_get_accounts.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.1.0

TDQS

A4.5/5.0
Behavior5/5

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

The annotations already mark the tool as read-only, and the description adds substantial behavioral detail: the default returns up to 100 unread plus recent read notifications, pages 2+ contain only older read notifications, page size is server-controlled and variable, and page length must not be used to infer counts or remaining history. This goes well beyond what annotations provide.

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 front-loaded with the tool's purpose and then organizes pagination behavior and fields guidance in a logical order. It is longer than minimal, but every sentence carries operationally important information for correct paging and efficient response handling.

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 supplies enough return-shape information (notification content, read/unread status, timestamps, related cards/comments) and covers all parameter behavior, pagination edge cases, and the empty-array termination signal. The read-only safety is already captured by annotations, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description mirrors the schema's page and fields explanations and adds only minor framing like 'what needs my attention' and 'typically several times smaller,' but it does not provide new parameter-level meaning.

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: 'Get notifications for the current user in an account,' and lists what is returned (notification content, read/unread status, timestamps, related cards/comments). This clearly distinguishes it from sibling tools that operate on boards, cards, or comments, even without naming them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use-case guidance: the default response is 'what you want for what needs my attention,' pages 2+ are for walking older history, and fields='summary' is recommended for scanning or listing. It does not explicitly name alternatives or when-not-to-use conditions, so it falls just short of a 5.

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

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/Fabric-Pro/fizzy-mcp'

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