Skip to main content
Glama
Sign In
Nucleo for WordPress

Nucleo for WordPress

by nucleowp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

nucleo-doc-validate

Read-onlyIdempotent

Validate a Nucleo document before saving to catch schema errors and see a quality report, including layout-level issues like duplicate H1s in headers or footers.

Instructions

Validates a document without saving it: schema errors and, if the document is valid, a quality report. A page or post is checked inside the site layouts it will receive (header, footer, single/product layout of postType), as doc-create does: a duplicate h1 in the header counts.

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": {
      "document": "<document>"
    },
    "name": "nucleo-doc-validate"
  }
}

Input Schema

NameRequiredDescriptionDefault
documentYesComplete Nucleo document (schema, root).
postTypeNoPost type the new content will have (default page). A content without postId is checked inside the layouts of that type, as doc-create and site-import do: post gets the single layout, product the product layout.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive) and the description is consistent with them. It adds real behavioral context beyond annotations: the tool returns schema errors and, only on a valid document, a quality report, and validation is layout-context-aware so a duplicate h1 in the header counts. It stops short of describing pagination/error semantics or the report's shape.

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?

Two front-loaded sentences: the core behavior and return values come first, then the layout-context nuance. The second sentence is dense but each clause (header/footer, single/product, duplicate h1 example) carries concrete information, with no filler.

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 does the work of telling the agent what comes back (schema errors, then a quality report) and under what condition each appears. Given only two parameters and full schema coverage, the remaining gap (exact report structure) is minor.

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 both parameters are already documented, and the description largely restates the schema's explanation of postType (single vs product layout, default page). The added value over the schema is marginal, which is the baseline-3 case.

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?

States a specific verb and resource (validates a document) plus the key differentiator 'without saving it', which separates it from nucleo-doc-create. It does not mention the sibling nucleo-model-validate, so an agent must infer which validator applies to which artifact, keeping this short of a 5.

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?

Clear context for use: a dry-run check of a page or post before it is persisted, evaluated inside the layouts it would receive. No explicit exclusions or named alternatives (e.g. 'use doc-create to save', 'use model-validate for model schemas') are given, so it stops at clear-context-without-routing.

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