Skip to main content
Glama

mcp-easy-ai__wp_list_comments

Read-only

Lists WordPress comments. Optional: post_id (filter by post — omit for all posts) or post_ids (several posts), post_exclude, status (approve/hold/spam/trash/all/any/post-trashed — default "approve" for published comments; use "hold" to list the pending moderation queue; "all" is approved plus pending, "any" is every status) or statuses (several), type (default "comment"; "all" lists every type except block editor notes, as the Comments screen does; also pingback, trackback, pings, note or a custom type), search, author (filter to a registered author user ID), author_exclude (array of author user IDs to exclude), author_email, author_url, include / exclude (comment IDs), parent / parent_exclude (parent comment IDs; [0] = top-level only), after/before (ISO 8601 date-time bounds), post_type, post_status, post_author, post_parent, post_name (filters on the comment's post), karma, meta_key with optional meta_value and meta_compare (protected meta keys, those sta… Through Royally: its server marks it read-only, so it runs straight away.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number for pagination.
typeNoComment type. Default "comment" (WordPress's REST default). "all" lists every type except block editor notes, which is what the Comments screen shows; "pings" is pingbacks and trackbacks; "note" lists block editor notes; any other value is matched as a custom comment type.
afterNoOnly comments posted on or after this ISO 8601 date-time (e.g. "2026-01-01T00:00:00").
karmaNoOnly comments with exactly this karma value.
orderNoSort direction. Default "desc".
authorNoFilter to comments by this registered (logged-in) author user ID.
beforeNoOnly comments posted on or before this ISO 8601 date-time (e.g. "2026-12-31T23:59:59").
offsetNoSkip this many matching comments before the first one returned. When greater than 0 it overrides page.
parentNoOnly replies to these parent comment IDs; [0] lists top-level comments only.
searchNoSearch query to filter comments.
statusNoFilter comments by status. "all" is approved plus pending; "any" is every status, spam, trash and post-trashed included; "post-trashed" is a comment whose post is in the Trash.
excludeNoExclude these comment IDs.
includeNoOnly these comment IDs.
orderbyNoSort by this attribute. Default "date_gmt". "include" keeps the order of the include list.
post_idNoFilter comments by post ID.
site_idNoSite to run this tool on: 8ef2e52b-bd07-4671-a363-ebe8b480b65c (https://demo.royalplugins.com)
meta_keyNoOnly comments that have this comment meta key. A protected key (starting with an underscore) needs the manage_options capability.
per_pageNoNumber of comments per page (1-100).
post_idsNoFilter to comments on any of these post IDs (0 = comments attached to no post). Use instead of post_id, not together with it.
statusesNoFilter to comments in any of these statuses (same values as status). Use instead of status, not together with it.
post_nameNoOnly comments on the post with this slug.
post_typeNoOnly comments on posts of this post type, or a comma-separated list of post types.
author_urlNoOnly comments whose author URL is exactly this value.
meta_valueNoWith meta_key: only comments whose value for that key matches (see meta_compare). Requires meta_key.
post_authorNoOnly comments on posts written by this user ID.
post_parentNoOnly comments on child posts of this post ID.
post_statusNoOnly comments on posts with this post status, or a comma-separated list of statuses.
author_emailNoOnly comments whose author email is exactly this address.
meta_compareNoWith meta_key: how meta_value is compared. Default "=". IN, NOT IN, BETWEEN and NOT BETWEEN take a comma-separated meta_value.
post_excludeNoExclude comments on these post IDs.
author_excludeNoArray of author user IDs to EXCLUDE from results.
parent_excludeNoExclude replies to these parent comment IDs; [0] excludes top-level comments.
include_detailsNoAlso return, for each comment: author (user ID, 0 for a guest), author_url, author_ip, author_user_agent, date_gmt, type, karma, comment_approved (raw stored value), content_raw (unrendered content) and link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare the tool read-only, non-destructive, and closed-world, and the description reinforces the read-only behavior. It adds useful behavioral context beyond annotations, such as protected meta keys requiring `manage_options` and status semantics including the default approval state. It still does not discuss result shape or pagination behavior.

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

Conciseness2/5

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

The purpose is front-loaded, but the rest is a long run-on enumeration of nearly every parameter, duplicating the fully described schema. It is not concise, and the text appears truncated near "those sta…", reducing readability.

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

Completeness3/5

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

The description is complete enough for parameter selection given its exhaustive filter list and the 100% schema coverage. However, with no output schema it does not explain the default return shape, pagination metadata, or total-count behavior, leaving a meaningful gap for a list operation.

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 description coverage is 100%, so the schema already documents all 33 parameters thoroughly. The description largely repeats those parameter meanings, though it adds a small amount of extra guidance such as the default `approve` status and using `hold` for the pending queue.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Lists WordPress comments." That is clear enough to distinguish it from single-comment tools like `wp_get_comment` and mutation tools like `wp_approve_comment`. It does not explicitly name sibling alternatives, so it stops short of full sibling differentiation.

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

Usage Guidelines2/5

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

The definition explains many filter options but gives no explicit guidance on when to use this tool versus `wp_get_comment`, `wp_get_pending_comments`, or other comment-list tools. The note to use `hold` for the pending moderation queue is parameter guidance, not tool-selection guidance.

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