nc-mcp-server

list_users

Read-onlyIdempotent

Retrieve Nextcloud users with server-side pagination. Filter by name or email and control page size and offset to navigate through large user lists.

Instructions

List Nextcloud users. Uses server-side pagination.

Args: search: Optional search string to filter users by name/email. limit: Maximum number of users to return (1-200, default 25). offset: Number of users to skip for pagination (default 0).

Returns: JSON with "data" (list of user ID strings) and "pagination" (count, offset, limit, has_more).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`search`	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.6/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive behavior. The description adds valuable context about server-side pagination, parameter constraints (limit 1-200), and the exact response shape (data list and pagination object). This goes beyond the annotations by explaining how results are returned and paginated.

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 tightly written with a clear front-loaded purpose, then a structured Args section, then a Returns section. No redundant sentences or fluff – every line serves a purpose.

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 list operation, the description covers everything an agent needs: purpose, pagination behavior, all parameters, and the return format. With an output schema present, the agent can rely on the structure, but the description already explains it. No gaps are apparent.

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 coverage is 0%, so the description fully compensates by explaining each parameter: search filters by name/email, limit caps the count with range and default, offset controls pagination with default. This adds meaning far beyond the raw schema which only lists types and defaults.

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 clearly states 'List Nextcloud users' – a specific verb and resource – and distinguishes itself from sibling tools like get_user (single user) and create_user (creation). The mention of server-side pagination further clarifies its scope as a bulk listing operation.

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?

It's evident this tool is for listing multiple users, and the pagination parameters imply it's for iterating over large sets. While it doesn't explicitly exclude alternatives, the tool name and description make its purpose unambiguous, and no similar listing tool exists in the sibling set.

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

Deploy Server