Skip to main content
Glama

Apply kit block

apply_kit_block
Destructive

Place a library block (slug) into a page file as a copy with fresh ids (pageId; before/after = exact text there; position 0 = top). To design a section for this business, write it with edit_site_file and use get_block as reference. Guide: get_style_reference({ topic: "blocks" }).

Input Schema

NameRequiredDescriptionDefault
idNoSite id.
slugNoBlock slug from search_blocks.
afterNoExact page text to insert after.
beforeNoExact page text to insert before.
pageIdNoTarget page (default page_home).
positionNo0 = top of the page body (default: end).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / after
      Added value: +{
      +  "description": "Exact page text to insert after.",
      +  "maxLength": 2000,
      +  "type": "string"
      +}
    • addedInput schema / properties / before
      Added value: +{
      +  "description": "Exact page text to insert before.",
      +  "maxLength": 2000,
      +  "type": "string"
      +}
    • removedInput schema / properties / contentOverrides
      Removed value: -{
      -  "description": "JSON object: node displayName → { text, url, alt, src, … }. Repeated names take an array, consumed in DFS order, e.g. { \"Heading\": { \"text\": \"Our Services\" }, \"Title\": [{ \"text\": \"SEO\" }, { \"text\": \"PPC\" }] }.",
      -  "maxLength": 65536,
      -  "type": "string"
      -}
    • changedInput schema / properties / position / description
      Previous value: -"Index among the page's sections (default: end)."New value: +"0 = top of the page body (default: end)."
    • removedInput schema / properties / propOverrides
      Removed value: -{
      -  "description": "JSON object: displayName → { className, replaceClassName?, props }. className merges unless replaceClassName: true. Arrays for repeated names.",
      -  "maxLength": 65536,
      -  "type": "string"
      -}
    • removedInput schema / properties / sectionContainerId
      Removed value: -{
      -  "description": "Existing empty section to fill (skeleton fills). Omit otherwise.",
      -  "maxLength": 256,
      -  "type": "string"
      -}
    • changedInput schema / properties / slug / description
      Previous value: -"Block slug from search_blocks. Not with sourceNodeId."New value: +"Block slug from search_blocks."
    • removedInput schema / properties / sourceNodeId
      Removed value: -{
      -  "description": "Page section on this site to deep-clone with fresh ids. Page target only.",
      -  "maxLength": 256,
      -  "type": "string"
      -}
    • removedInput schema / properties / target
      Removed value: -{
      -  "description": "page (default) | header (replaces hdr_root) | footer (replaces ftr_root).",
      -  "enum": [
      -    "page",
      -    "header",
      -    "footer"
      -  ],
      -  "maxLength": 128,
      -  "type": "string"
      -}
  2. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"Site id. Pass it on every call."New value: +"Site id."
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false. The description adds non-obvious behavior beyond that: the inserted content is a copy with fresh ids, so the library source is untouched, and placement is controlled by exact anchor text or position 0. It does not spell out permission requirements or whether the page must be unpublished, which is the remaining gap for a destructive write.

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?

Three tight clauses, front-loaded with the action and its core semantics, then the alternative and the reference guide. No filler sentences; every clause carries information an agent needs.

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 6-parameter destructive mutation with no output schema, the description covers placement mechanics, the copy semantics, and the main alternative path. It stops short of stating what is returned (e.g., the new block ids) or any precondition on the target page, which leaves a modest gap for a write tool with destructiveHint=true.

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 description coverage is 100%, so the schema already documents id, slug, after, before, pageId and position. The description restates the same semantics (before/after as exact text, position 0 = top, slug as a library block) without adding format, precedence (what happens if both before and after are given), or default details beyond the schema. Baseline 3 applies.

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 (place) and resource (library block identified by `slug`) plus the destination (a page file) and the key transformation (a copy with fresh ids). It also names the sibling tools it is not — get_block for reference, edit_site_file for custom design — so an agent can route correctly 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 Guidelines4/5

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

Gives an explicit alternative path: to design a section for this business, write it with edit_site_file and use get_block as reference. That is real when-not guidance. It does not explicitly say to find the `slug` via search_blocks/list_blocks in the description (that lives only in the schema), so it falls just short of full when/when-not coverage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources