Skip to main content
Glama

List conversations

nextcloud_list_conversations
Read-onlyIdempotent

Retrieve all conversations the account participates in, including talk rooms, so you can review and manage active chats.

Instructions

List the conversations the account takes part in.

GET /ocs/v2.php/apps/spreed/api/v4/room

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nextcloud_list_conversations"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond them — results are limited to conversations the authenticated account participates in, not all rooms on the instance. It says nothing about pagination, ordering, or result size, and the trailing "GET /ocs/v2.php/..." line largely restates the read-only annotation.

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?

The operative sentence is front-loaded and free of filler. The raw endpoint path on a second line is mildly redundant with readOnlyHint and adds provenance rather than agent-relevant meaning, but it costs little.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with full annotation coverage, the call mechanics are adequately covered. However, with no output schema, the description should say something about what a conversation record contains or whether results are paginated — an agent has no idea what it will get back.

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?

The tool takes zero parameters, so there is no parameter semantics to document; the empty schema is self-explanatory. Baseline for a no-parameter tool applies, with no missing input information.

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 and resource ("List the conversations") with an explicit scope qualifier, "the account takes part in," which distinguishes it from a server-wide room listing and from the singular nextcloud_get_conversation. It does not name any sibling tool outright, so differentiation is inferable rather than stated.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer this is the discovery call before nextcloud_get_conversation, nextcloud_list_messages, or nextcloud_list_participants, but the description never says so. No when-not-to-use, no pagination or filtering guidance, and no alternatives are named.

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

Deploy Server

Other Tools