Governed ability
Get users
aafm/get-users Read only
List users: id, display name, email, roles, and post count. Response includes total (the full match count). Gated by the list-users capability. Never login or password.
How it is governed
The same model as every ability in the plugin, stated for this one.
- Off until you enable it
Like every ability, Get users ships switched off. You turn it on one at a time, and an update never widens access on its own.
- Reads only
It reads data and returns it to your client. Nothing on your site is created, changed, or removed.
- Capability gated
A connection only sees Get users if the user you connected can run it, and the plugin checks that capability again before it executes.
- Every call audited
The call is written to the log in your own database, denials included, with the argument keys but never the values.
See it in action
An illustrative run. Your real calls and data stay on your own site.
Try it with a prompt
Example requests you could paste to your agent.
List the users on the site with their roles and post counts.
Show me everyone with an editor role and how many posts each has.
Give me the site users along with their display names and email addresses.
These are illustrative example prompts. The agent runs them as the user you connected, checked against that user's capabilities and written to your audit log.
Frequently asked
Short answers for Get users.
Does this expose logins or passwords?
No. It returns id, display name, email, roles, and post count only. Usernames used to log in and passwords are never included.
What controls who can run it?
It is gated by the list-users capability and off by default. An agent only sees this data if the connected account already has permission to list users, and every call is audited.
Governed by default, from the first call.
Get users is off until you enable it, scoped to the user you connect, and logged like everything else. Turn on only what you need.
Every ability off until you enable it, capability-gated on every call.