Skip to main content
Glama
Sign In
Nucleo for WordPress

Nucleo for WordPress

by nucleowp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

nucleo-layout-explain

Read-onlyIdempotent

Shows the resolved layout for each area of a WordPress URL and explains which rule selected, excluded, superseded, or applied it before you edit a layout.

Instructions

For a URL, shows for each area the resolved layout and the key that chose it (matched) with a readable rule, or null. If a layout is excluded for that URL, the area reports excluded with the layout and the rule (by). Areas product and product-archive exist only with WooCommerce, on a product and on the Shop or a product archive; elsewhere they are null. They win over single and archive (search also wins over archive): the losing area reports superseded with the winning area. applied is what the page really prints, area → layout id, after the page settings and document layout "none": read it before editing a layout. postId is the post of the URL (url_to_postid, 0 if none), keys are the request keys tried, conflicts are the priority conflicts of the map (as in layout-list).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "nucleo-layout-explain"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes

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 readOnlyHint/idempotentHint/destructiveHint, so safety is covered; the description goes further by disclosing conditional behavior (product and product-archive areas only exist under WooCommerce) and precedence rules (those areas win over single/archive, search wins over archive), plus what 'applied' means after page settings and a document layout of 'none'. It omits auth or rate-limit context, but adds substantial behavioral detail beyond the annotations.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a single dense run-on that strings together vocabulary terms (matched/by/applied/superseded/conflicts) without formatting, and near-duplicate parentheticals ('(search also wins over archive)') interrupt flow. Every clause carries information, yet the packaging makes it harder to parse than necessary.

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?

With no output schema, the description must carry the return-value burden alone, and it largely does: it defines each field concept (matched rule, excluded with 'by', superseded with winning area, applied map, postId, keys, conflicts). Some labels ('by', 'keys') are named but not fully specified, leaving minor gaps for a tool whose output is an explain-style report.

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 0% with a single required 'url', and the description only implicitly characterizes it as a front-end request URL resolved via url_to_postid (0 when none). That is useful meaning beyond the bare string type, but there is no guidance on URL form (absolute vs relative, trailing slash, query strings) despite the 2048-char cap.

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 a specific verb and resource: for a given URL it resolves the layout per area plus the rule/key that selected it, and it enumerates the possible outcomes (matched, excluded, superseded, null, applied). It also carves out its own niche relative to layout-list by noting conflicts are reported 'as in layout-list', so an agent can tell it apart from the sibling listing tool.

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 a clear workflow instruction: 'read it before editing a layout' — establishing this as the diagnostic step prior to mutation. It does not, however, name a when-not-to-use case or route to a specific alternative (e.g. layout-list or layout-conditions-set) for related questions, so guidance stops short of explicit alternatives.

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