nc-mcp-server

list_conversations

Read-onlyIdempotent

Retrieve every Nextcloud Talk conversation you have joined, sorted by recent activity, with pagination and modified-since filtering to track changes.

Instructions

List Talk conversations the current user is part of.

Returns every conversation the user has joined, sorted by last activity (newest first). Muted and archived conversations are included; Talk has no filter for them.

Args: limit: Maximum number of conversations to return (1-200, default 50). offset: Number of conversations to skip for pagination (default 0). modified_since: Only conversations with activity since this ISO 8601 time with time zone, e.g. to check what changed since the last look. Your own changes to a conversation (read state, favorite, archive, notifications) count as activity, and ones with a call running are always included.

Returns: JSON with "data" (list of conversation objects) and "pagination" (count, offset, limit, has_more).

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.9.0Oct 1, 2026

removedInput schema / properties / include_notifications_disabled

Removed value: -{
-  "default": false,
-  "title": "Include Notifications Disabled",
-  "type": "boolean"
-}

addedInput schema / properties / modified_since

Added value: +{
+  "default": "",
+  "title": "Modified Since",
+  "type": "string"
+}

First observedv0.7.0Sep 21, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare the safe read-only/idempotent profile, so the bar is lower; the description still adds genuinely non-obvious behavior: sort order by last activity, mute/archive inclusion, and the modified_since quirk that the user's own read-state/favorite/archive changes count as activity and in-call conversations are always returned. No auth or rate-limit context is offered, keeping it from a 5.

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 purpose, then Args, then Returns, with every line carrying information. The Returns block restates what the output schema already declares, which is mild redundancy, and the docstring-style layout is slightly heavier than necessary.

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?

An agent has everything it needs: what the list contains, ordering, the three parameters with formats and defaults, and the envelope of the response (even if redundant with the output schema). Nothing required 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 the full burden and does so: limit with range 1-200 and default 50, offset as a pagination skip with default 0, and modified_since with ISO 8601-with-timezone format plus the semantic rules for what counts as activity. This is meaning well beyond the bare typed properties.

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 ('List Talk conversations') and narrows scope to conversations the current user is part of, which cleanly separates it from get_conversation, search_mentions, and the thread/subscription tools. The inclusion rule (joined conversations, newest-first) makes the result set unambiguous.

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?

Gives clear context for when this tool applies (enumerate joined conversations, check what changed via modified_since) and explicitly notes that muted/archived are included with no filter available, which preempts a wrong choice. It never names an alternative sibling (e.g. get_conversation for a single one), so it stops short of explicit when-not guidance.

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

Deploy Server