Skip to main content
Glama

nucleo-gap-report

Report missing Nucleo capabilities before using a workaround, logging the need, affected block or page, and fallback so recurring gaps are tracked.

Instructions

Call this whenever Nucleo cannot do what the design needs, before any workaround. need: what is missing (1-500 characters). block: the nc/... block concerned, if any. workaround: what you did instead (at most 1000 characters); the workaround goes in style.custom of the node, never in mu-plugins, theme code or wp_head. page: the page concerned (at most 200 characters). Repeating the same block and need increases the count.

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": {
      "need": "<need>"
    },
    "name": "nucleo-gap-report"
  }
}

Input Schema

NameRequiredDescriptionDefault
needYesWhat Nucleo cannot do.
pageNoPage concerned.
blockNoNucleo block concerned, such as nc/section-ref.
workaroundNoWhat was done instead, in style.custom of the node.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare a non-idempotent, non-destructive write, and the description adds real behavior beyond them: repeating the same block+need increments a count (dedup/aggregation semantics), and workarounds must live in the node's style.custom, never in mu-plugins, theme code or wp_head. It still does not say what the call returns or where reports surface, and there is no output schema to compensate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The triggering condition is front-loaded in the first clause, then each parameter is covered in a single tight fragment with its constraint inline. Nothing extraneous; the telegraphic style suits a frequently called tool.

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 write tool with no output schema, the definition covers trigger, per-parameter rules, deduplication, and the workaround-placement policy. The remaining gap is what the agent gets back (a report id or updated count) and whether gaps are reviewed via nucleo-gap-list; neither is stated.

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 100%, so baseline is 3, but the description goes further: it names the block format (nc/...), supplies an example (nc/section-ref), reveals that block+need together form the dedup key, and imposes a placement constraint on workaround that the schema does not state. That is meaning added on top of the schema rather than a restatement.

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?

"Call this whenever Nucleo cannot do what the design needs, before any workaround" plus the need/block/workaround/page fields makes the resource (a gap report about a missing Nucleo capability) clear, and the unique 'gap' framing distinguishes it from the doc/content/config siblings. It never states the action verb explicitly (files/records a report), leaning on the tool name, which keeps it below 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 Guidelines4/5

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

The trigger is explicit and well-scoped: invoke when Nucleo cannot do what the design needs, and do so before any workaround is attempted. That is a genuine when-to-use rule with precedence. It does not name the read-side sibling (nucleo-gap-list) as the alternative for reviewing existing reports, so full alternative routing is absent.

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