Skip to main content
Glama

List End Users

list_users
Read-only

The window's END USERS as a ranked register: who your agents served.

The end user is the person on the other side of the agent — the user.id your SDK stamps — not a console login and not an org member. The words are worth keeping straight: an ORG is the Rius customer, a WORKSPACE is one of their own clients, and an end user is that client's user.

Read a user_id off this register and pass it to user_activity_summary for that person's KPIs, or to list_agent_traces(user_id=...) for their runs. This is the same read the console's Users page makes.

TOP-N by design, not by accident: a B2C workspace can hold millions of end users, so the server ranks and caps. When it reports more, q reaches PAST the cap by exact id — it is an equality probe, never a substring search, so a fragment finds nothing rather than scanning millions of ids.

Three figures that are easy to misread, so each travels with its caveat: anonymous traffic is always reported and is a real subject rather than an error case; coverage is counted in TRACES because one trace can belong to two end users under the any-span rule; and a null cost means nothing in the window was priced, which is not the same as free.

workspace: optional workspace id, name, or org-name/workspace-name when the same name occurs in two of your orgs (defaults to your default; use list_workspaces to discover them). hours: lookback window in hours (default 24), used for whichever of start/end is not given. The register is an unindexed group-by, so the window is capped at 31 days and a wider one is refused. start: optional absolute RFC3339 lower bound (e.g. "2026-08-01T00:00:00Z"); overrides the hours-derived value when given. end: optional absolute RFC3339 upper bound; overrides the hours-derived value when given. sort: "traces" (default), "failed_traces", or "cost" — all descending. A value outside that set is refused rather than quietly defaulted, since a wrong ranking under a right-looking header cannot be caught later. limit: users per page (default 20, server max 100). q: an EXACT end-user id. Returns that user's row even when they fall outside the top-N, or an empty register when the window holds nothing for them.

Example:

Who are my busiest end users this week?

{ "name": "list_users", "arguments": { "hours": 168 } }

Which end users are seeing the most failures?

{ "name": "list_users", "arguments": { "hours": 168, "sort": "failed_traces" } }

Is u_8f2 in the last 30 days at all?

{ "name": "list_users", "arguments": { "hours": 720, "q": "u_8f2" } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
endNo
sortNotraces
hoursNo
limitNo
startNo
workspaceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint, but the description adds the operational envelope: TOP-N ranking by server-side cap, q as an equality probe rather than substring search, a hard 31-day window that is refused if exceeded, refusal of out-of-set sort values, and the caveats on anonymous traffic, trace-based coverage, and null cost. This is disclosure well beyond the annotations.

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 and well-sectioned, with parameters and examples following the framing. It is longer than strictly necessary, though: the 'words are worth keeping straight' exposition and some of the caveat prose lean narrative where a tighter phrasing would lose nothing.

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 output schema exists, so return values needn't be spelled out, and the description instead fills every remaining gap an agent needs: entity scope, window semantics and cap, ranking behavior, the id-probe escape hatch, and three figures called out as easy to misread. Nothing material for correct invocation 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 coverage is 0% (bare types and defaults only), so the description carries the full burden and does: all seven parameters are documented with semantics, defaults, and edge behavior (hours vs start/end precedence, workspace name disambiguation, sort's allowed set and refusal, limit's server max, q's exact-match-only rule). This is exactly the compensation a low-coverage schema needs.

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?

Opens with a specific verb+resource framing ('END USERS as a ranked register') and immediately scopes the entity by contrasting it against two look-alikes: console logins and org members. It also disambiguates the whole vocabulary chain (org/workspace/end user), so an agent can tell exactly what population this returns before opening any schema.

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

Usage Guidelines5/5

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

Explicit downstream routing: read a user_id here and pass it to user_activity_summary or list_agent_traces(user_id=...). It also states the exact condition that selects the `q` path (a user outside the top-N) and how q behaves when it misses, which is the main alternative-use decision for this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources