Skip to main content
Glama
Sign In
Nucleo for WordPress

Nucleo for WordPress

by nucleowp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

nucleo-tokens-set

Idempotent

Update design tokens by sending only changed values; changes merge with saved tokens and defaults, and the response lists contrast issues caused in published documents.

Instructions

Edits the design tokens (groups color, space, text, font, radius, shadow, container). Only the values to change are sent; they are merged with the saved tokens and the defaults; null removes a key (back to the default, or gone if the key is new). A new key extends a scale: {"space": {"20": 6}} creates $space.20 (keys: lowercase letters, digits and -, at most 48 per group). Units: space and text in rem, text as [minRem, maxRem], container as integer px. Invalid values or unknown groups return invalid_tokens. The result lists the contrast problems the new tokens cause in published documents (up to 50). Full rules: nucleo/catalog-get {"topic": "tokens"}.

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": {
      "tokens": "<tokens>"
    },
    "name": "nucleo-tokens-set"
  }
}

Input Schema

NameRequiredDescriptionDefault
tokensYesToken groups, for example {"color": {"primary": "#1d4ed8"}, "space": {"4": 1}, "text": {"xl": [1.25, 1.5]}, "container": {"lg": 1200}}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare non-read-only, idempotent and non-destructive, and the description goes well beyond that: it explains merge semantics, that null reverts a key to default (or deletes a new key), the 48-keys-per-group cap, unit conventions, the invalid_tokens error on bad values or unknown groups, and that the result reports contrast problems in published documents (up to 50). That is unusually rich behavioral disclosure for a mutation tool.

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?

The core action and merge model are front-loaded, and nearly every sentence carries distinct operational information. It is a dense, unbroken block of prose, though, and the inline JSON example adds length that could have been tightened.

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?

With no output schema available, the description compensates by describing the return value (contrast problems caused in published documents, capped at 50) and the error case (invalid_tokens). For a single-parameter mutation tool with nested objects, nothing an agent needs to invoke it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100% for the single nested tokens object, but the description still adds substantial meaning: merge-versus-replace behavior, null-as-removal, scale extension via {"space": {"20": 6}} creating $space.20, key charset and length limits, and per-group units including the [minRem, maxRem] tuple for text. This is meaning the schema alone does not convey.

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?

The description opens with a specific verb and resource ('Edits the design tokens') and enumerates the exact groups it governs (color, space, text, font, radius, shadow, container). That enumeration lets an agent separate this from the read-side sibling nucleo-tokens-get without opening either schema.

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?

It clearly frames the operating mode — send only the values to change, they merge with saved tokens and defaults — which tells an agent when this tool is the right call versus a full replacement. It also routes to nucleo/catalog-get {"topic": "tokens"} for full rules, though it never states when not to use this tool or which sibling to prefer for reading tokens.

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