Skip to main content
Glama

nucleo-doc-create

Create WordPress pages, posts, layouts, or sections from a Nucleo document, attach one to existing content, and optionally publish or dry-run with quality checks.

Instructions

Creates a page, post, layout or section from a Nucleo document; without postType the type follows document.kind (layout and popup: nucleo_layout, section: nucleo_section). With postId it attaches the document to an existing content without a Nucleo document; on a published content an OAuth token also needs the scope nucleo:publish. The slug comes from slug, document.wp.slug or document.meta.slug, then from the title, also for drafts; a taken slug gets a suffix and a warning. Quality is checked on the page composed with the site layouts it will receive (header, footer, single or product layout), also for a new content: an h1 in the header counts. With publish true it publishes, but blocking quality issues require acknowledge. With dryRun true it does not save. Returns postId, revision and slug.

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-create"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNoSlug of the new content (a-z, 0-9, -). Without it the slug comes from document.wp.slug or document.meta.slug (normalized as WordPress does), then from the title. If the slug is taken, a suffix is added: the output slug and a warning say so.
titleNoRequired without postId.
dryRunNo
postIdNoExisting content without a Nucleo document: the document is attached to it. Type, title and status stay as they are.
publishNo
documentYesNucleo document in compact or full form.
postTypeNoWithout it the type comes from document.kind: layout and popup create a nucleo_layout, section a nucleo_section, any other kind a page. page and post refuse the kinds layout, popup and section.
acknowledgeNoQuality issues acknowledged, with a reason.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the non-mutating safety profile is covered; the description adds genuinely useful behavior: slug collisions get a suffix plus a warning, quality checks run against the composed page including site layouts (header h1 counts), and an OAuth scope nucleo:publish is needed on published content. What it does not disclose is whether dryRun and publish can be combined or what a failed quality check returns, so it stops short of full behavioral coverage.

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 the core verb and resource, then proceeds through type, attach mode, slug, quality, and publish behavior in a logical order. It is dense and semicolon-heavy, making it harder to scan than it needs to be, but every clause carries distinct information with no 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 an 8-parameter creation tool with nested objects and no output schema, the description covers the tricky parts: type inference, the postId attach path, slug derivation precedence, quality gating, and the return values (postId, revision, slug). An agent can call it correctly and interpret the result without consulting other sources.

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 75%, so baseline is roughly 3; the description earns the bump by giving meaning to the undocumented parameters: dryRun ('does not save'), publish (publishes, but blocking issues require acknowledge), and acknowledge (issues acknowledged with a reason). For slug and postType it largely restates the schema's own fallback and enum rules rather than adding new detail.

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?

Specific verb plus resource: 'Creates a page, post, layout or section from a Nucleo document', and it immediately clarifies the type-resolution rule so an agent can tell it apart from nucleo-doc-patch and nucleo-doc-preview. The four creatable content types and the postId attach-mode are named explicitly, leaving no ambiguity about scope.

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?

Gives conditional usage for the key modes: without postType the type follows document.kind, with postId it attaches to existing content, with publish true it publishes (requiring acknowledge for blocking issues), with dryRun true nothing is saved. It does not name sibling alternatives such as previewing via nucleo-doc-preview before creating or using nucleo-doc-publish for existing documents, so routing guidance is contextual but not exhaustive.

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