Nucleo for WordPress

Overview Schema Source Related Servers Discussions Admin

nucleo-site-import

Idempotent

Import site-export files to create or update WordPress tokens, sections, pages, posts, layouts, menus, media and settings. Use dryRun to validate every document without writing.

Instructions

Imports the files produced by nucleo/site-export: creates or updates tokens, sections, pages, posts, layouts, rules, media, menus and site settings (title, tagline, homepage, language). With dryRun true it validates every document like a real import (schema and blocking quality issues) without writing. With force true it also imports the posts, tokens and site settings modified on the site after the export; with force as a list of file paths (e.g. ["pages/home.json"], "site.json" for tokens and settings) only those files. acknowledge carries the blocking issues a human has accepted, per file. The report returns the new base (base, tokensBase) to write into site.json. Quality is checked on the page composed with the site layouts it will receive (header, footer, single or product), also for new pages. Pages and posts are imported before layouts, because layout conditions refer to them (page:): a page is checked against the layouts already on the site, not those of the same import. content/ and terms/ files are not handled here: they go to content-upsert and terms-set.

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": {
      "files": "<files>"
    },
    "name": "nucleo-site-import"
  }
}

Input Schema

Name	Required	Description
`files`	Yes	Relative path → JSON content, as in nucleo/site-export.
`force`	No	true for every file, or the file paths to overwrite even if they changed on the site (nucleo push --force <file>).
`dryRun`	No
`pending`	No	dryRun only: symbols of the published content items and terms that the same push creates first, e.g. "evento:congresso", "page:servizi/consulenza", "term:area/nutrizione". Menu items and site settings treat them as found. nucleo push --dry-run sends them.
`acknowledge`	No	File path → blocking quality issues accepted by a human, as in nucleo/doc-publish. Ask the user first and quote the consent in reason.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the write/idempotency profile is structured. The description nonetheless adds substantive behavior: validation semantics of dryRun (schema plus blocking quality issues), that unknown documents are skipped in dryRun, and that quality is checked against the layouts already on the site rather than same-import layouts. It leaves some tension unaddressed: force overwriting files modified on the site reads as a potentially destructive action while destructiveHint=false, and no rollback or partial-failure behavior is described.

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?

Purpose is front-loaded in the first clause and every subsequent sentence carries operational detail rather than filler. The middle section becomes dense and comma-chained (the force and acknowledge sentences pack several rules into one line), which costs some scannability but not correctness.

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?

This is a complex, multi-modal mutation tool with nested objects and no output schema, and the description covers the pieces an agent needs: import ordering (pages and posts before layouts, and why), the returned base/tokensBase to write into site.json, dryRun validation scope, and the pending-symbols interplay. Nothing material for correct invocation appears missing.

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 80% and already documents force, pending and acknowledge in some depth. The description still adds value by giving example force paths ('pages/home.json', 'site.json' for tokens and settings) and by tying acknowledge to the human consent flow ('Ask the user first and quote the consent in reason'), which elaborates the nested object's purpose. Files and dryRun gain little beyond 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?

States a specific verb and resource ('Imports the files produced by nucleo/site-export') and then enumerates exactly what gets created or updated: tokens, sections, pages, posts, layouts, rules, media, menus and site settings. It also explicitly carves out content/ and terms/ to content-upsert and terms-set, so the agent can separate this tool from siblings without opening their schemas.

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?

Gives concrete when-to-use variants: dryRun true to validate without writing, force true for the full set or force as a list of paths for selected files, with example paths and the note that 'site.json' covers tokens and settings. It also names the exclusion condition ('content/ and terms/ files are not handled here: they go to content-upsert and terms-set'), which is exactly the alternative routing an agent needs.

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

Deploy Server