Skip to main content
Glama
Sign In
Nucleo for WordPress

Nucleo for WordPress

by nucleowp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

nucleo-catalog-get

Read-onlyIdempotent

Fetch full block manifests by name, compact manifests for up to 20 blocks, or topical reference rules to guide correct WordPress page and layout generation.

Instructions

With name: full manifest of a Nucleo block (content, settings, supports, allowed children, hints for the AI), the style keys of its groups with CSS property and allowed values, its HTML markup, its base CSS and an example node built from its required content and settings. With names (up to 20): a compact entry per block, without base CSS; the style keys of all their groups appear once in styleKeys. The response stays under 25,000 characters: names that do not fit are listed in remaining, to request in a second call. With topic: reference rules that are not in any manifest: documents, tokens, styles, bindings, visibility, data, theme, site-files, acknowledge, components, model, layouts, woocommerce.

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-catalog-get"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoName of the block, e.g. "nc/heading".
namesNoNames of several blocks, e.g. ["nc/heading", "nc/button"]. Returns one compact entry per name in blocks; names over the size limit go to remaining.
topicNotokens: groups, keys, units, merge rules. styles: every style key by group. bindings: sources, empty values, repeaters, relations, escape. visibility: breakpoints, visitor and field conditions. data: repeaters, related posts, terms, breadcrumbs. theme: base HTML and CSS, section widths, links. site-files: files of site-import/export and push, import order, dry-run. acknowledge: where it is saved, sections. components: what PHP components can do. layouts: areas, condition types and their format, how a layout is chosen.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered; the description goes further by disclosing a hard 25,000-character response cap, the resulting "remaining" overflow list, and that multi-name mode drops base CSS and de-duplicates style keys into a single styleKeys collection. Those are real behavioral traits an agent must plan around and are not in the schema. What is missing is what happens with zero arguments or an unknown block name.

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?

The text is organized strictly by input mode (name / names / topic) and leads with the highest-value case, so an agent can scan to its relevant branch. Sentences are long and clause-dense, and the trailing topic list repeats the schema enum verbatim, which is wasted space.

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?

There is no output schema, so the description has to carry the return contract, and it does so thoroughly for all three modes, including truncation handling. Gaps remain for a three-optional-parameter tool: no-argument behavior and multi-parameter interaction are undefined, and no guidance is given on invalid block names.

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 100%, so the baseline is 3, and the description earns more by explaining the cross-parameter consequence of `names`: style keys of all their groups appear once in styleKeys, and names beyond the size limit go to `remaining`. The `topic` semantics are largely duplicated from the enum descriptions rather than extended. The unresolved question of precedence among the three optional parameters keeps it below 5.

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 enumerates exactly what each mode returns: a full manifest (content, settings, supports, allowed children, AI hints, group style keys with CSS properties and values, HTML markup, base CSS, example node), a compact per-block entry for multi-name calls, and reference topics. That is far more specific than a restated title, and it distinguishes itself from nucleo-catalog-list by returning block detail rather than a listing. It stops short of a clean verb-first statement and never contrasts itself with siblings like nucleo-tokens-get, which also surface token reference material.

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?

"With name:", "With names (up to 20):" and "With topic:" form an explicit mode-selection guide, and the note that overflowed names should be requested in a second call tells the agent how to recover from a truncated result. However, no exclusion is given against sibling reference tools (nucleo-tokens-get, nucleo-guide, nucleo-model-get), and the description never says whether name, names and topic are mutually exclusive or can be combined in one call.

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