Skip to main content
Glama

UiChemy AI Website Creator

uichemy_add_section

Destructive

Adds a LIBRARY layout (one from uichemy_find_templates / uichemy_list_templates) to a page. For a new section designed for this site, which is what "add / create / design a … section" usually means, use uichemy_design_section and uichemy_add_designed_section instead. OVERWRITES copy when text is passed: slot tokens belong to the LAYOUT, so text for a layout already used elsewhere in the project replaces that copy there too. Add a section to a page at a position. Both documents are updated together — the sitemap node that says the page HAS a section there, and the variant map that says what renders in it. Updating one alone is how 'add a pricing section' silently repeats the hero. Fill its slots: call uichemy_template_slots and pass text, or the section renders its own tokens. BLOG PAGES ARE CONSTRAINED. A blog listing page takes navbar, blog, newsletter, footer; a blog detail page takes those plus the single-post sections. A hero, a pricing table or an FAQ on one is refused, not added.

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": {
      "projectId": "<projectId>",
      "pageName": "<pageName>",
      "kind": "<kind>",
      "variant": "<variant>"
    },
    "name": "uichemy_add_section"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesA section folder from uichemy_list_section_kinds — hero, pricing, faq…
textNo
indexNoWhere to put it, 1-based, as uichemy_get_page lists them — 1 puts it first. Omitted = at the end.
imagesNo
variantYesA layout id from uichemy_list_templates — "layout-y3", or a number for numbered folders (3 and website3 are the same layout).
pageNameYes
projectIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the destructiveHint annotation: it explains that passing `text` OVERWRITES copy globally wherever the layout is used, and that both the sitemap node and variant map are updated together to avoid duplicate sections. These are non-obvious destructive side effects the annotations alone could not convey.

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 core verb and the routing decision, and each block (overwrite warning, dual-document update, blog constraints) earns its place. It is dense and slightly verbose with all-caps emphasis, but no sentence is disposable.

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 destructive 7-param mutation with no output schema, the description covers the workflow, the destructive copy behavior, and page-type constraints thoroughly. The main omission is any explanation of the `images` parameter and expected return, minor given the otherwise rich context.

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?

At 43% schema coverage the description must compensate, and it does well for `text` (slot tokens, overwrite semantics, call uichemy_template_slots) and implies the ordering role of `index`. However `images`, `projectId`, and `pageName` are left undocumented in both schema and description, leaving a gap.

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 ('Adds a LIBRARY layout ... to a page') and immediately contrasts with the siblings uichemy_design_section and uichemy_add_designed_section. An agent can distinguish this from the design-from-scratch path without opening any 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?

Explicitly names when to use this vs the alternative ('for a new section designed for this site ... use uichemy_design_section and uichemy_add_designed_section instead'), and adds a hard constraint on blog pages (allowed vs refused section kinds). Routing and exclusion conditions are both covered.

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