MCP servers that can list users
4 verified servers expose a tool that can list users in a workspace
Most agent actions in a workspace need a person's id, not their name. Listing users is how an agent resolves a handle to that id before it assigns work, mentions someone, or reports on who belongs.
These verified servers return the members of a chat workspace or server. A note on scope: this is the people inside the workspace, the colleagues in your Notion or Discord, not the end-users of an application you built.
Notion
Notion
Notion's hosted MCP server lets agents search, read, and write across your workspace over OAuth.
notion-get-users
Working off a Notion workspace, notion-get-users lists the workspace's users with their details, the directory an agent reads to turn a name into the person id a share or assignment needs.
Discord MCP
barryyip0625
Maintained community MCP server that lets an agent run a Discord bot: messages, channels, forums, roles, and webhooks.
discord_list_members
discord_list_members returns a server's members along with their roles, so an agent sees not only who is in the server but what each can do.
Rocket.Chat
enyonee
Community MCP server for Rocket.Chat: read and post messages, manage threads, DMs, files, reactions, and pins across your team chat.
list_users
On a self-hosted Rocket.Chat server, list_users enumerates the accounts on the server, the membership lookup for teams running their own chat.
Matrix
mjknowles (community)
A self-hosted MCP server for Matrix homeservers that lets agents read rooms and messages, send chats, and manage rooms over HTTP with OAuth.
get-all-users
get-all-users reads known users from the Matrix client cache rather than querying the homeserver, a fast local view of who the client has already seen.
What to know
The shape of the list follows the product. Notion returns workspace users with their details, the directory you read to map a name to a person before sharing a page or recording an owner. Discord lists members of a server together with their roles, so an agent can check who can do what, not just who is present. Rocket.Chat and Matrix come at it from the chat side, one enumerating the server's accounts, the other reading the known users from the client cache rather than querying the homeserver fresh. Same intent, different source of truth.
Membership changes slowly, so the name-to-id map an agent builds from one listing stays good across sessions. That is the payoff worth carrying forward: an agent that already resolved alex to a user id, or learned which handful of people own which areas, skips the directory call and acts. Re-listing every run to find the same person is the cold start you avoid.
Questions
- Are these the end-users of my app, or the people in my workspace?
- The people in your workspace. Each tool lists the members of a Notion workspace, a Discord server, or a chat server, the colleagues and teammates who hold accounts there. None of them lists the end-users of an application you built; that data lives in your own database, not in the chat or workspace server.
- Why list users before assigning or mentioning someone?
- Because the write tools want an id, not a display name. Listing resolves a handle like alex to the user id an assignment, mention, or share call expects. With Discord you also get each member's roles in the same response, which lets an agent check permissions before it acts rather than after.