Skip to main content
Glama

mcp-easy-ai__wp_list_terms

Read-only

Lists terms of ANY taxonomy exposed in the REST API — media folders such as mlo-category, product categories and brands (product_cat, product_brand), ACF or other custom taxonomies, as well as category and post_tag. Use wp_get_taxonomies to discover the taxonomy slugs. Required: taxonomy (the taxonomy slug). Optional: search, parent (filter by parent ID; use 0 for top-level only), per_page (default 100), page, orderby (id/term_id/name/slug/count/include/term_group/description/parent/term_taxonomy_id/none/meta_value/meta_value_num — default name), order (asc/desc), hide_empty (boolean, default false), and the get_terms() filters include / exclude / exclude_tree / term_taxonomy_id (arrays of IDs), slug / name (arrays of exact values), child_of (every descendant of a term), childless (boolean), name__like / description__like (substring), pad_counts (boolean: add descendants' counts to each parent's count), meta_key with optional meta_value and meta_compare (needs … Through Royally: its server marks it read-only, so it runs straight away.

Input Schema

NameRequiredDescriptionDefault
nameNoOnly terms with one of these names (the whole name, not a part of it; see name__like for that).
pageNoPage number for pagination.
slugNoOnly terms with one of these slugs.
orderNoSort direction.asc
parentNoParent term ID to filter by (hierarchical taxonomies only; 0 for top-level terms).
searchNoSearch query to filter terms.
excludeNoLeave out these term IDs.
includeNoOnly these term IDs. WordPress ignores exclude and exclude_tree when include is given, so they cannot be combined.
orderbyNoField to order results by. term_id is the same as id; include keeps the order of `include`; none leaves the database order; meta_value and meta_value_num (numeric) sort by the value of `meta_key`, which they require.name
site_idNoSite to run this tool on: 8ef2e52b-bd07-4671-a363-ebe8b480b65c (https://demo.royalplugins.com)
child_ofNoOnly descendants (children, grandchildren and so on) of this term ID. Hierarchical taxonomies only; cannot be combined with a parent above 0, which WordPress lets override it. total and total_pages then count the descendants (counted separately, since WordPress's own total ignores child_of).
meta_keyNoOnly terms that have this term meta key (in plain printable ASCII, no spaces). Needs the taxonomy's edit_terms capability, the one reading term meta needs; a protected key (starting with an underscore) also needs manage_options. Also the key orderby meta_value / meta_value_num sorts by.
per_pageNoNumber of terms per page (1-100).
taxonomyYesThe taxonomy slug (e.g. category, post_tag, product_cat, mlo-category). Use wp_get_taxonomies to list the available slugs.
childlessNotrue: only terms that have no children.
hide_emptyNoWhether to hide terms with no objects assigned.
meta_valueNoWith meta_key: only terms whose value for that key matches (see meta_compare). Requires meta_key; must not be empty (to match any value use meta_compare EXISTS).
name__likeNoOnly terms whose name contains this text.
pad_countsNotrue: each term's count also includes the objects of its descendants. Hierarchical taxonomies only (a flat taxonomy has no descendants).
include_urlNotrue: add each term's archive URL as `url`. Default false.
exclude_treeNoLeave out these term IDs and every descendant of each.
meta_compareNoWith meta_key: how meta_value is compared. Default "=". IN and NOT IN take a comma-separated meta_value, BETWEEN and NOT BETWEEN exactly two comma-separated values; EXISTS and NOT EXISTS need no meta_value.
term_taxonomy_idNoOnly terms with these term_taxonomy_id values.
description__likeNoOnly terms whose description contains this text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already flag readOnlyHint=true and destructiveHint=false, and the description is consistent with that ("its server marks it read-only, so it runs straight away"). It adds real context the annotations don't cover: `meta_key` filtering needs the taxonomy's edit_terms capability, and protected keys additionally need manage_options. The garbled/truncated final sentence ("needs … Through Royally") cuts off part of that permission discussion.

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 first two sentences are well front-loaded, but the rest degenerates into a single run-on enumeration of ~20 parameters that duplicates the schema, and it terminates in corrupted text ("needs … Through Royally"). For a tool with full schema coverage, that bulk does not earn its place.

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?

There is no output schema, so the description should hint at the return shape; it only obliquely references total/total_pages (inside the child_of note) and the optional `url` field from include_url. It also breaks off mid-sentence on meta filtering permissions, leaving the agent with an incomplete picture for a 24-parameter tool.

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 every one of the 24 parameters, including defaults and enums. The description largely restates those same definitions inline (parent = 0 for top-level, pad_counts meaning, orderby default name), adding convenience but little genuinely new semantics beyond the child_of/parent override note.

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 opening sentence states a specific verb and resource ("Lists terms") and deliberately broadens the scope to "ANY taxonomy exposed in the REST API," naming concrete examples (mlo-category, product_cat, post_tag, ACF taxonomies). That scope statement implicitly separates it from the category/tag-specific siblings like wp_list_categories and wp_list_tags.

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?

It gives an explicit prerequisite workflow: "Use `wp_get_taxonomies` to discover the taxonomy slugs," and states the required `taxonomy` argument. It stops short of telling the agent when to prefer this over wp_list_categories / wp_list_tags / wp_get_terms or when to use wp_count_terms instead.

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