uCoz

Read users

users_read

Read-onlyIdempotent

Reads site users and profiles, user groups, group permissions, ranks and profile fields.

Input Schema

Name	Required	Description
`id`	No	Group id.
`gid`	No	Group id. On group actions it is a synonym for id.
`nick`	No	User login (nick), 2-25 characters. Synonym: user.
`page`	No	List page, from 1.
`user`	No	Synonym for nick.
`email`	No	User email.
`action`	Yes	Operation to run. Each oneOf entry describes one action and lists its parameters.
`detail`	No	Record form of a paged list. brief (default): id, login, full name, email, group, status (active or banned) and registration date (UTC, ISO 8601). Titles and excerpts are plain text; names, logins, paths, URLs and other identifiers are as the source gives them. full: complete records. A list reply is at most 30 KB and holds every record of its page: a record that does not fit in full comes in brief form, marked detail brief, the reply counts such records in brief_records, and get by id returns the complete record; brief records shorten their excerpts, then keep only their ids and titles. Only a page that does not fit even so is cut: truncated is true and next names the offset to go on from.
`offset`	No	Records to skip from the start of a list; overrides page. A list reply cut at its size limit names the offset that follows in next.
`user_id`	No	Numeric user id.
`per_page`	No	Records per page: 1-50, 20 by default, larger values count as 50.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

changedInput schema / properties / action / oneOf

Previous value: -[
-  {
-    "const": "list",
-    "description": "Lists site users page by page, optionally filtered by login, id or email. Brief users by default; detail=full gives complete profiles, get one complete user. The reply has page, per_page, total, has_more, truncated and next. Optional: page, per_page, offset, detail, nick, user, user_id, email."
-  },
-  {
-    "const": "get",
-    "description": "Returns one user by id, login or email. Optional: user_id, nick, user, email."
-  },
-  {
-    "const": "groups",
-    "description": "Lists user groups. Optional: offset."
-  },
-  {
-    "const": "groups_list",
-    "description": "Lists user groups (same as groups). Optional: offset."
-  },
-  {
-    "const": "groups_rights",
-    "description": "Lists the permission codes that a group can have. Optional: offset."
-  },
-  {
-    "const": "group_permissions",
-    "description": "Returns the permissions of one group (group id in id or gid). Optional: id, gid."
-  },
-  {
-    "const": "ranks",
-    "description": "Lists user ranks. Optional: offset."
-  },
-  {
-    "const": "fields",
-    "description": "Lists user profile fields. Optional: offset."
-  }
-]New value: +[
+  {
+    "const": "list",
+    "description": "Lists site users page by page, optionally filtered by login, id or email. Brief users by default; detail=full gives complete profiles, get one complete user. The reply has page, per_page, total, has_more, truncated and next. Optional: page, per_page, offset, detail, nick, user, user_id, email."
+  },
+  {
+    "const": "get",
+    "description": "Returns one user by id, login or email. Required: user_id or nick or user or email."
+  },
+  {
+    "const": "groups",
+    "description": "Lists user groups. Optional: offset."
+  },
+  {
+    "const": "groups_list",
+    "description": "Lists user groups (same as groups). Optional: offset."
+  },
+  {
+    "const": "groups_rights",
+    "description": "Lists the permission codes that a group can have. Optional: offset."
+  },
+  {
+    "const": "group_permissions",
+    "description": "Returns the permissions of one group (group id in id or gid). Required: id or gid."
+  },
+  {
+    "const": "ranks",
+    "description": "Lists user ranks. Optional: offset."
+  },
+  {
+    "const": "fields",
+    "description": "Lists user profile fields. Optional: offset."
+  }
+]

Changed5 schema fields changedOct 20, 2026

changedInput schema / properties / action / oneOf

Previous value: -[
-  {
-    "const": "list",
-    "description": "Lists site users page by page, optionally filtered by login, id or email. Optional: page, nick, user, user_id, email."
-  },
-  {
-    "const": "get",
-    "description": "Returns one user by id, login or email. Optional: user_id, nick, user, email."
-  },
-  {
-    "const": "groups",
-    "description": "Lists user groups."
-  },
-  {
-    "const": "groups_list",
-    "description": "Lists user groups (same as groups)."
-  },
-  {
-    "const": "groups_rights",
-    "description": "Lists the permission codes that a group can have."
-  },
-  {
-    "const": "group_permissions",
-    "description": "Returns the permissions of one group (group id in id or gid). Optional: id, gid."
-  },
-  {
-    "const": "ranks",
-    "description": "Lists user ranks."
-  },
-  {
-    "const": "fields",
-    "description": "Lists user profile fields."
-  }
-]New value: +[
+  {
+    "const": "list",
+    "description": "Lists site users page by page, optionally filtered by login, id or email. Brief users by default; detail=full gives complete profiles, get one complete user. The reply has page, per_page, total, has_more, truncated and next. Optional: page, per_page, offset, detail, nick, user, user_id, email."
+  },
+  {
+    "const": "get",
+    "description": "Returns one user by id, login or email. Optional: user_id, nick, user, email."
+  },
+  {
+    "const": "groups",
+    "description": "Lists user groups. Optional: offset."
+  },
+  {
+    "const": "groups_list",
+    "description": "Lists user groups (same as groups). Optional: offset."
+  },
+  {
+    "const": "groups_rights",
+    "description": "Lists the permission codes that a group can have. Optional: offset."
+  },
+  {
+    "const": "group_permissions",
+    "description": "Returns the permissions of one group (group id in id or gid). Optional: id, gid."
+  },
+  {
+    "const": "ranks",
+    "description": "Lists user ranks. Optional: offset."
+  },
+  {
+    "const": "fields",
+    "description": "Lists user profile fields. Optional: offset."
+  }
+]

addedInput schema / properties / detail

Added value: +{
+  "description": "Record form of a paged list. brief (default): id, login, full name, email, group, status (active or banned) and registration date (UTC, ISO 8601). Titles and excerpts are plain text; names, logins, paths, URLs and other identifiers are as the source gives them. full: complete records. A list reply is at most 30 KB and holds every record of its page: a record that does not fit in full comes in brief form, marked detail brief, the reply counts such records in brief_records, and get by id returns the complete record; brief records shorten their excerpts, then keep only their ids and titles. Only a page that does not fit even so is cut: truncated is true and next names the offset to go on from.",
+  "enum": [
+    "brief",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Records to skip from the start of a list; overrides page. A list reply cut at its size limit names the offset that follows in next.",
+  "type": "number"
+}

changedInput schema / properties / page / description

Previous value: -"Page number of the user list."New value: +"List page, from 1."

addedInput schema / properties / per_page

Added value: +{
+  "description": "Records per page: 1-50, 20 by default, larger values count as 50.",
+  "type": "number"
+}

AddedOct 19, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds no behavioral context beyond the resource list — nothing about per-action required parameters, pagination/size-limit behavior (which sits in the schema), or what a caller gets back per action.

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?

A single front-loaded sentence naming verb and resources, with no filler. It is efficient, though for an 11-parameter, 8-action tool the brevity edges toward under-specification.

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 multi-action read tool with no output schema, the description should at minimum flag the action-dispatch model and that required parameters vary per action. The rich enum descriptions compensate substantially, but the top-level description leaves the agent to discover the dispatch contract from the schema.

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% and the action enum documents each operation and its parameters in detail, so the schema carries the full burden. The description contributes nothing to parameter meaning; baseline 3 applies.

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 (Reads) and enumerates the resources covered: site users and profiles, user groups, group permissions, ranks and profile fields. It is clear enough to distinguish the read surface from users_write/users_delete by name, but it never says the tool is action-dispatched, so an agent cannot tell from the description alone that one call must pick among list/get/groups/ranks/fields.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no alternatives named, and no statement that this is the read counterpart to users_write/users_delete. Any routing information lives in the action enum descriptions, not in the tool description itself.

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

All uCoz tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Read users

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources