Skip to main content
Glama
Sign In
Nucleo for WordPress

Nucleo for WordPress

by nucleowp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

nucleo-content-get

Read-onlyIdempotent

Retrieve a content item by type and slug with all fields and a hash to detect changes before saving, preventing unnecessary overwrites during upserts.

Instructions

Returns one content item by type and slug, with all its keys and "hash": pass it as "base" to content-upsert, which then saves only if the item did not change since. The item can be sent back to content-upsert as it is (hash, id and protected are ignored). Returns not_found when no item has that slug, read_only_type for product (listed by content-list, never read or written here).

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": {
      "type": "<type>",
      "slug": "<slug>"
    },
    "name": "nucleo-content-get"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesItem slug.
typeYesContent type, for example "post" or "page".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered upstream. The description still adds real behavior beyond them: the two failure outcomes (not_found for an unknown slug, read_only_type for product) and the fact that hash, id and protected are ignored when the item is sent back to content-upsert.

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 purpose and packed with useful detail in three sentences, with no filler. The nested quoting of "hash": pass it as "base" makes the middle clause a little hard to parse on first read, which keeps it short of a 5.

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 carries the burden of return shape and does so partially, telling the agent the item comes back with all its keys plus hash, id and protected, and enumerating error codes. It stops short of describing the keys themselves, but for a two-parameter read that is close to complete.

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 coverage is 100% and both parameters carry inline descriptions, so the baseline is 3. The description adds only the type-level caveat that product is rejected, not slug syntax, casing, or format rules, so it does not materially deepen parameter meaning 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: "Returns one content item by type and slug." It also delimits scope by naming what is not handled here (product/read_only_type, which content-list covers), so an agent can separate it from the list and upsert siblings without opening a schema.

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 an explicit use case — fetch an item, then pass its "hash" as "base" to content-upsert for conditional saving — and an explicit exclusion: product is never read here and is listed by content-list instead. That is when-to-use, when-not, and a named alternative in one compact block.

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