Skip to main content
Glama
Sign In
Nucleo for WordPress

Nucleo for WordPress

by nucleowp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

nucleo-doc-get

Read-onlyIdempotent

Reads a Nucleo WordPress document as compact or full JSON, optionally scoped to a subtree or depth, and returns its revision for conflict-safe patching.

Instructions

Nucleo document in compact form (default) or in full (format "full": the stored document unchanged), whole or only a subtree (nodeId), with a maximum depth (depth, compact only). Also returns the revision: pass it as baseRevision to doc-patch, which refuses with conflict if the document changed since.

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

Input Schema

NameRequiredDescriptionDefault
depthNoBeyond this depth, children are replaced by childCount. Not used with format "full".
formatNocompact
nodeIdNoId of the node where the subtree starts.
postIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: the revision is returned and acts as an optimistic-concurrency token for doc-patch, and depth truncation replaces children with childCount in compact mode. It stops short of describing error behavior (e.g. unknown postId/nodeId).

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?

A single dense sentence front-loads the core purpose and nests the modifiers in parentheses. Every clause carries information, though the stacked parentheticals make it slightly harder to parse than separate sentences would be.

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?

For a four-parameter read tool with annotations but no output schema, the definition covers modes, scoping, depth behavior and the returned revision. The remaining gap is error/failure behavior and the meaning of postId, which is minor relative to the tool's simplicity.

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 50%, so the description carries weight: it defines what format "full" means (the stored document unchanged) versus compact, establishes that nodeId scopes the subtree, and reiterates that depth is compact-only. The depth semantics largely duplicate the schema's own description, and postId remains unexplained in both places, but overall it adds meaningful meaning.

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 names the resource (Nucleo document) and precisely describes what is returned: compact vs full stored document, whole document or a subtree via nodeId, depth-limited descendants, plus the revision. It is clearly a read/retrieval operation. It does not explicitly distinguish itself from sibling readers such as nucleo-doc-texts or nucleo-doc-list, which keeps it from 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the described variants (use format "full" when you need the stored document unchanged, nodeId for a subtree, depth to limit payload). The one explicit routing statement is forward-looking: pass the returned revision as baseRevision to doc-patch, which refuses with a conflict if the document changed. There is no explicit when-not guidance or comparison against the other document-reading siblings.

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