Skip to main content
Glama

get_users_community_space

Read-onlyIdempotent

Retrieve a paginated list of users in a community space, sorted from oldest to newest. Use this read-only lookup to audit or report on community members without making any changes.

Instructions

๐ŸŸข READ-ONLY ยท GET /v2/community/spaces/{id}/users

Get users of a community space. Returns a list with all the users of the space. The users are in sorted order, with the oldest created user appearing first, and the list is paginated, with a default limit of 10 users per page.

Behavior: read-only lookup against the live school; creates, changes and deletes nothing. Auth (admin API token + Lw-Client id) is injected server-side, never by the model; calls are throttled to stay under LearnWorlds' 30-per-10s cap and retried on 429/5xx. Parameters: results are paged โ€” walk them with page and size each page with items_per_page. Returns: HTTP <status> followed by the LearnWorlds JSON response body. A non-2xx reply surfaces as a tool error with that status and the API error payload โ€” 401 bad/expired token, 403 not permitted, 404 no such record, 422 rejected input. Use when: safe to call speculatively for lookups and reporting. Not for changing anything โ€” use the matching ๐ŸŸก write tool. Related Community tools: add_invite_users_community_space, remove_user_community_space, delete_community_space, get_community_space, update_community_space.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesUnique identifier of the community space
pageNoFilter by the page number. In case page number is higher than the maximum one, the results of last page will be returned
items_per_pageNoFilter by the items per page number

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

The description adds read-only semantics beyond annotations: no creates/changes/deletes, auth injected server-side, throttling/retry behavior, pagination and error surfacing. This is valuable context the annotations do not provide.

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 description is longer than minimal but structured with headers and packed with useful details. It is front-loaded with READ-ONLY and the endpoint, so the extra length is justified.

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 read-only list tool with no output schema, it covers purpose, pagination, sorting, auth behavior, throttling, and error handling. Nothing needed to invoke it correctly is missing.

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?

Schema covers 100% of parameters, so baseline is 3; the description adds the actionable pagination pattern 'walk them with page and size each page with items_per_page' and notes the API default limit of 10 per page. This goes slightly beyond schema.

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 opens with the exact verb and resource: 'Get users of a community space' plus the endpoint. It clearly states the return is a paginated list of users in sorted order, and names related Community tools so it is distinguishable from get_community_space/get_community_spaces and the write tools.

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 gives an explicit 'Use when...' section: safe for speculative lookups and reporting, and 'Not for changing anything โ€” use the matching write tool'. It lists related Community tools, though it could more directly say 'use get_community_space for space metadata rather than its users'.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ohneben/Learnworlds-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server