UiChemy AI Website Creator

uichemy_add_shop_pages

Give a store (WooCommerce) project its standard shop pages - the same nine the UiChemy app adds, under the same names: Shop Page, Product Category, Product Single, Product Search Results, My Cart, Checkout, My Account, Order details, Track Your Order. They go in the Shop Pages group, and each wears the Woo Navbar (cart, account, product search) - the site's own when a page has one - and the site's one normal Footer. On a store the core and legal pages wear the Woo Navbar too; only the blog keeps the normal Navbar, whose search finds posts. For a site that SELLS PRODUCTS ONLINE (an online store, e-commerce, a product shop such as a flower or shoe shop, or a business that says it sells its products online), call this rather than building those pages one by one: the export, the cart, the checkout and the account area expect these pages by these names. NOT for a service business that is merely called a shop - a barber shop, coffee shop, repair shop, tattoo shop or salon books appointments, it does not sell online - unless the user asks for an online store. Pages that already exist are left alone, so calling it twice adds nothing. Text slots on the new pages start empty - fill them with uichemy_get_page and uichemy_set_text.

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>"
    },
    "name": "uichemy_add_shop_pages"
  }
}

Input Schema

Name	Required	Description	Default
`layouts`	No	Layout per section folder - { "woo-product-listing": "layout-y2" }. Anything omitted takes the folder's first layout; navbar and footer follow the site's own.
`projectId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare it is not read-only and not destructive; the description adds substantial behavioral context beyond that — existing pages are left untouched (idempotent), text slots start empty, the Shop Pages group placement, and navbar/footer inheritance rules. It does not describe the response, but no output schema exists and this gap is minor.

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 action and page list, followed by the crucial use/don't-use routing. It is long but nearly every sentence carries routing or behavioral information; only the navbar/footer detail is slightly verbose.

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 mutation tool with no output schema, the description covers what gets created, what happens to existing pages, and text-slot state. The remaining gap is that the layouts parameter and projectId are never explained, which an agent would need to consult the schema for.

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

Parameters2/5

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

Schema coverage is only 50%; the layouts parameter is documented in the schema, but projectId has no description anywhere. The description never mentions either parameter or how to supply layout overrides, so it does not compensate for the coverage 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?

The description states a specific verb and resource ('Give a store (WooCommerce) project its standard shop pages') and enumerates all nine pages by name. It is clearly distinguishable from siblings like uichemy_add_page and uichemy_add_blog.

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 it (sites that sell products online, e-commerce, product shops like flower or shoe shops) and when not to (service businesses merely called a shop: barber, coffee, repair, tattoo, salon). It also states the alternative (building pages one by one) and the idempotency behavior on repeat calls.

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

All UiChemy AI Website Creator tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?