Skip to main content
Glama
ArsNovaSingers

ars-nova-wordpress-mcp

Official

List WordPress Users

wp_list_users
Read-onlyIdempotent

List WordPress users with search, role filters, and pagination. Use edit context to include roles and capabilities for security audits.

Instructions

List users on the WP site. Use context='edit' to see roles/capabilities (requires admin).

Args:

  • limit (number): Page size, 1-100. Default 20.

  • offset (number): Pagination offset.

  • search (string): Optional keyword filter (matches username, email, name).

  • roles (string[]): Optional filter to users in these roles.

  • orderby (enum): id | name | registered_date | slug | include. Default 'name'.

  • order (enum): asc | desc. Default 'asc'.

  • context (enum): view | embed | edit. Default 'view'. Use 'edit' to get roles/capabilities.

  • response_format (enum): markdown | json. Default 'markdown'.

Returns: Paginated envelope of WPUserItem objects with shape: { id, name, slug, url, description, link, roles?, capabilities?, registered_date? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results to return (1-100). Default 20.
orderNoSort direction.asc
rolesNoFilter to users in any of these roles (e.g. ['administrator', 'editor']).
offsetNoNumber of results to skip for pagination. Default 0.
searchNoSearch term to match against username, email, name.
contextNoWP REST context. 'edit' returns roles/capabilities/email but requires list_users capability.view
orderbyNoSort field.name
response_formatNoOutput format: 'markdown' for human-readable, 'json' for machine-readable.markdown
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: the 'edit' context requires admin and returns roles/capabilities, and the response is a paginated envelope with a defined shape. This enriches the agent's understanding without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence purpose, a bulleted args list, and a returns section. Every line earns its place, and the most important information (what it lists, the admin requirement for context='edit') is front-loaded. It is long due to the number of parameters, but not verbose or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though there is no output schema, the description provides the returned object shape, which is essential for an agent to understand the result. It also covers pagination, filters, enums, defaults, and the admin requirement. Lacking only explicit error scenarios or rate limits, but for a read-only list tool with robust annotations, this is nearly complete.

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 coverage is 100%, and each parameter's description in the schema is already very informative. The tool description largely repeats the schema (e.g., limit, search, orderby) with only a slight simplification—notably, it says 'requires admin' where the schema more precisely says 'requires list_users capability'. The description adds minimal new meaning beyond the schema, so a baseline score of 3 is appropriate.

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 'List users on the WP site', a clear verb+resource statement. It distinguishes this from sibling tools like wp_get_user (single user) and wp_list_posts, and further clarifies that context='edit' reveals roles/capabilities. This is specific and unambiguous.

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?

The description provides clear usage context for the 'edit' context ('requires admin') and explains pagination/filtering parameters. However, it does not explicitly mention when this tool should be preferred over alternatives like wp_get_user or how it differs from other list tools. It provides good context but no explicit exclusions or alternative comparisons.

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/ArsNovaSingers/ars-nova-wordpress-mcp'

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