Skip to main content
Glama

UiChemy AI Website Creator

uichemy_template_slots

Read-only

Not needed to start a new site: uichemy_create_project with page names only picks every layout. Useful for changing one section. What copy a template needs, slot by slot: WHAT EACH SLOT IS — headline, eyebrow, primaryButton, cardTitle, price, quote — and WHERE IT SITS ("plans 2 of 3", "section header"), plus the template's sample copy and the MOST CHARACTERS it takes. The layout was designed around the sample's length; copy over max is refused by the editing tools (uichemy_create_project builds anyway and lists it). Write to about the sample's length, and put each piece of copy in the slot whose for matches it — a name in the name slot, a review in the review slot. READ THIS BEFORE WRITING COPY, and fill every slot: a UiChemy template renders its TOKEN, so a slot left empty puts text_a1b2c3 on the page at whatever size the design paints it. There is no placeholder to improve on later — unfilled is broken. Pass every layout you are going to use in layouts to get all their slots in one call.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "uichemy_template_slots"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNo
layoutsNoSeveral layouts at once: [{ "kind": "hero", "variant": "layout-y2" }, { "kind": "faq", "variant": "layout-x3" }].
variantNoA layout id — "layout-x6", or a number / websiteN for numbered folders.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / layouts
      Added value: +{
      +  "description": "Several layouts at once: [{ \"kind\": \"hero\", \"variant\": \"layout-y2\" }, { \"kind\": \"faq\", \"variant\": \"layout-x3\" }].",
      +  "items": {
      +    "properties": {
      +      "kind": {
      +        "type": "string"
      +      },
      +      "variant": {
      +        "type": [
      +          "string",
      +          "number"
      +        ]
      +      }
      +    },
      +    "required": [
      +      "kind",
      +      "variant"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 60,
      +  "type": "array"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "kind",
      -  "variant"
      -]
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint:false annotations, it discloses real downstream consequences: copy over `max` is refused by editing tools while uichemy_create_project builds anyway and lists it, and an unfilled slot renders a raw token like `text_a1b2c3` at design size. That is exactly the behavioral context an agent needs before writing copy.

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

Conciseness3/5

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

The content is all substantive, but the presentation is jumbled: ALL-CAPS fragments, em-dashes, and parentheticals interrupt the flow, and the confusing first clause precedes the actual purpose. Front-loading a clearer statement of what is returned would improve it.

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?

There is no output schema, and the description compensates by enumerating what each returned slot contains (identity, position, sample copy, max length) plus the failure mode for empty slots. For a read-only, three-parameter tool, an agent has everything needed to call it and interpret the result.

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 67% and the `layouts` array already carries an example, but the description adds non-obvious semantics the schema lacks: batch all layouts to avoid multiple calls. The `kind` parameter remains unexplained in both schema and description, which keeps this below a 5.

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 makes clear this tool reports what copy a template/layout needs, slot by slot: slot names (headline, price, quote), placement ('plans 2 of 3'), sample copy, and max character counts. It distinguishes itself from uichemy_create_project and the editing tools, though the opening clause is a convoluted negative ('Not needed to start a new site') that front-loads a sibling comparison ahead of the actual purpose.

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?

It states when the tool is unnecessary (create_project with page names picks every layout), when it is useful ('changing one section'), and gives a directive trigger ('READ THIS BEFORE WRITING COPY'). It also tells the agent how to batch: pass every layout in `layouts` to get all slots in one call.

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