nc-mcp-server

list_notifications

Read-onlyIdempotent

Retrieve Nextcloud notifications for the current user, sorted newest first. Use limit and offset to paginate through up to 25 results per request.

Instructions

List notifications for the current Nextcloud user.

Returns notifications sorted by newest first. Note: the Nextcloud server returns at most 25 notifications and does not support server-side pagination, so the total available is capped by the server regardless of the limit value.

Args: limit: Maximum number of notifications to return (1-25, default 25). offset: Number of notifications to skip for pagination (default 0).

Returns: JSON with "data" (list of notification objects with notification_id, app, user, datetime, subject, message, and optionally link and actions) and "pagination" (count, offset, limit, has_more).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Sep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark it as read-only, idempotent, and non-destructive, so the description builds on those rather than repeating them. It adds meaningful behavioral detail: the server caps results at 25, no server-side pagination is supported, ordering is newest first, and the response shape includes data and pagination.

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 core purpose, followed by a necessary behavioral caveat and clearly structured Args and Returns sections. Every sentence adds useful information; there is no redundant or filler content.

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 simple two-parameter read-only tool, this description is complete: it covers purpose, parameter semantics, server limits, sorting, and return structure. The annotations plus output schema cover the remaining safety and response-format concerns, so nothing an agent needs to call it correctly is missing.

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 full responsibility for explaining the parameters. It clearly documents limit (range 1-25, default 25) and offset (number to skip, default 0), and explains the practical effect of the server cap on limit.

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 names a specific verb ('List'), a specific resource ('notifications'), and a clear scope ('for the current Nextcloud user'). It also adds the sorting behavior ('newest first'), which further distinguishes this from any activity or announcement listing sibling.

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 clearly frames when to use the tool (listing the current user's notifications) and provides important context about the 25-notification server cap. It does not explicitly name alternatives or exclusions, but the resource and scope are specific enough that an agent will not confuse it with action-oriented siblings like dismiss_notification.

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

Deploy Server