Skip to main content
Glama
Sign In
Nucleo for WordPress

Nucleo for WordPress

by nucleowp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

nucleo-bind-fields

Read-onlyIdempotent

Lists bindable fields for a post type across Nucleo model, WordPress meta, ACF, and Meta Box sources, showing which fields content-upsert can write and which are read-only.

Instructions

Fields of the content type a block can bind to: Nucleo model fields, WordPress meta, ACF, Meta Box and sources added by the filter. "writable" says whether content-upsert can write the field: only source nucleo (fields of the Nucleo content model) is writable; the others are read-only for Nucleo and "readOnly" says why. Edit those fields in the plugin that owns them: declaring the same key in model-set would replace its registration and value format.

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": {
      "postType": "<postType>"
    },
    "name": "nucleo-bind-fields"
  }
}

Input Schema

NameRequiredDescriptionDefault
postTypeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety bar is low; the description still adds real substance by explaining the writable/readOnly flags on returned fields and that only the nucleo source can be written by content-upsert. That is meaningful behavior beyond what the annotations provide, though the return payload details remain partial.

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?

Dense but front-loaded: sources first, then the writable/readOnly semantics, then the warning about model-set. It reads as one long run-on sentence with some density cost, but essentially every clause carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 well to name the writable and readOnly keys on returned fields. However, the overall shape of the response (list structure, per-source grouping, empty-result behavior) is still unstated, leaving an agent to discover the payload format on first call.

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 0% — postType carries no description in the schema — but the single parameter is self-describing and the description's phrase 'content type a block can bind to' conveys what it accepts. It stops short of stating accepted forms (slug, max 20 chars) or the error behavior for unknown types, so it only partly compensates for the coverage gap.

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 identifies the resource precisely: the fields of a content type that a block can bind to, enumerated by source (Nucleo model, WordPress meta, ACF, Meta Box, filter-added). The verb is implicit (a read/discovery operation) rather than stated, and no sibling is explicitly named, but an agent can tell this is a field-enumeration tool rather than the get/set field tools.

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?

It gives a clear negative-action rule: edit non-Nucleo fields in the plugin that owns them, and don't redeclare a key in model-set because that replaces the registration and value format. What it lacks is a positive trigger — when an agent should call this instead of nucleo-fields-get — leaving the usage context inferred from the name and subject matter.

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