Skip to main content
Glama
Sign In
Nucleo for WordPress

Nucleo for WordPress

by nucleowp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

nucleo-content-list

Read-onlyIdempotent

List paginated WordPress content to get item IDs for previews or full items with hashes for change-safe upserts; products are read-only and trashed items are excluded.

Instructions

Lists content items of the allowed content types, paginated. Without "full" each item is a summary with id (pass it as contextPostId to doc-preview). With full each item is complete and has "hash": pass it as "base" to content-upsert, which then saves only if the item did not change since; the item can be sent back as it is (hash, id and protected are ignored). product items are listed read-only: content-get and content-upsert do not handle them. Trashed items are never listed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nucleo-content-list"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoReturn complete items instead of summaries. Default false.
pageNoPage number. Default 1.
termNoOnly items with this term, as "<taxonomy>/<slug>".
typeNoContent type, for example "post" or "page". Omit to list all allowed types. "product" lists WooCommerce products, read only: content-upsert does not write them.
searchNoText to search in titles and content.
statusNoOnly items with this status. Default: all but trash.
perPageNoItems per page, from 1 to 100. Default 20.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses non-obvious behavior: trashed items are excluded, product items cannot be written by sibling tools, and the hash enables optimistic concurrency so upsert saves only when unchanged. It also states which fields are ignored on round-trip (hash, id, protected), which an agent could not infer from annotations.

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

Conciseness4/5

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

Front-loaded with purpose and mode split, and every sentence carries operational information. It is dense and somewhat run-on, mixing mode semantics, cross-tool handoffs, and read-only caveats into one paragraph, but no sentence is filler.

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

Completeness5/5

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

For a 7-parameter list tool with no output schema, the description covers mode selection, cross-tool parameter reuse, write-protection of products, and trash exclusion. An agent has enough to call it correctly and to chain the result into doc-preview or content-upsert.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3; the description earns above that by adding behavioral meaning to two parameters — what "full" returns and how its hash is consumed downstream, and that type="product" is a read-only path. It does not add anything about page/perPage/term/search, but those are fully documented in the schema.

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?

Opens with a specific verb and resource ("Lists content items of the allowed content types, paginated") plus explicit scope limits. It is clearly distinguishable from content-get (single-item) and content-upsert (write), which it names directly.

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

Usage Guidelines5/5

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

Defines two operating modes (summary vs "full") and states the condition selecting each, then routes the agent onward: summary ids go to doc-preview as contextPostId, full hashes go to content-upsert as "base". It also states exclusions: products are read-only and not handled by content-get/content-upsert, and trashed items are never listed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools