Ignix

Update the store page design and basics

update_store_theme

DestructiveIdempotent

Store administration: works on the business's own link-in-bio store or appointments/bookings landing in Ignix, which the user manages as its owner. Nothing is bought or sold in this chat; the store's customers buy on the store page, paid to the business's own Stripe account. Change how a public page looks — the store page (default) or the booking page (page: "booking") — and, for the store, its name and bio. Only what you pass changes. Design: a starting preset (cream, night, sunset, forest, editorial, lavender, noir, starry, blush), background and button colours (hex like "#1c1917"; the text colour is chosen automatically so it stays readable), font (inter, poppins, nunito, space, playfair), button shape (rounded, pill, square) and style (filled, outline), background effect (none, stars; stars suit dark backgrounds). Store only, the header (classic, cover, cover_avatar): classic = round avatar and name; cover = a full-width photo fading into the background with the name on it; cover_avatar = the photo with the avatar over its edge — with coverUrl, a photo uploaded with upload_media (null removes it; without a photo the header stays classic). Basics: title (the page name) and bio. slug is the PUBLIC address of the store (bio link): changing it breaks links already shared, so pass it only with confirmSlugChange: true after the user agreed; creating the store the first time also needs title and slug. Seller details (legal name, tax id, terms) and Stripe stay in the app. Confirm visible changes with the user.

Input Schema

Name	Required	Description
`bio`	No	Store only: short bio under the name, up to 300 characters. "" removes it.
`font`	No
`page`	No	Which page to design. Default store.
`slug`	No	Store only: public address (a-z, 0-9, "-"). Needs confirmSlugChange: true.
`shape`	No
`title`	No	Store only: page name, up to 80 characters.
`button`	No	Hex colour of the buttons.
`effect`	No
`header`	No	Store only.
`preset`	No
`coverUrl`	No	Store only: the cover photo, an https url from upload_media; null removes it.
`background`	No	Hex colour, e.g. "#fdf7f1".
`buttonStyle`	No
`workspaceId`	No	Defaults to the workspace this connection is scoped to.
`idempotencyKey`	No	Optional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.
`confirmSlugChange`	No	true only after the user agreed to set or change the public store address.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 21, 2026

addedInput schema / properties / coverUrl

Added value: +{
+  "description": "Store only: the cover photo, an https url from upload_media; null removes it.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / effect

Added value: +{
+  "enum": [
+    "none",
+    "stars"
+  ],
+  "type": "string"
+}

addedInput schema / properties / header

Added value: +{
+  "description": "Store only.",
+  "enum": [
+    "classic",
+    "cover",
+    "cover_avatar"
+  ],
+  "type": "string"
+}

changedInput schema / properties / preset / enum

Previous value: -[
-  "cream",
-  "night",
-  "sunset",
-  "forest",
-  "editorial",
-  "lavender"
-]New value: +[
+  "cream",
+  "night",
+  "sunset",
+  "forest",
+  "editorial",
+  "lavender",
+  "noir",
+  "starry",
+  "blush"
+]

First observedOct 17, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description goes far beyond what the destructive/idempotent annotations provide. It specifies crucial behavior, such as that 'Only what you pass changes' (partial updates), and details the necessary input flow for specific fields (e.g., `coverUrl` requires `upload_media`).

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?

While extremely detailed, the information is highly dense and well-structured. It effectively front-loads the scope and the critical functional boundaries before detailing the various options. The length is justified by the sheer number of complex constraints it must convey.

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?

Given the high complexity (16 parameters, mutation, conditional logic) and the absence of an output schema, the description is maximally complete. It addresses all potential ambiguities regarding parameter usage, change constraints, and system behavior.

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

Parameters5/5

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

With schema coverage at 69%, the description is essential. It translates generic schema types (strings) into operational meaning, explaining hex code formats, detailing font differences (e.g., 'inter, poppins, nunito...'), and providing visual definitions for header styles (e.g., 'classic = round avatar and name').

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 immediately defines the tool's function: modifying the store page design and basics. It specifies the resource (Ignix link-in-bio store or booking landing page) and distinguishes it from general store product updates by focusing solely on theme and look.

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 explicitly defines the operational scope (owner-managed, customer purchases handled externally via Stripe). Most critically, it provides precise conditional usage guidelines, warning that changing the slug breaks existing links and must only be done with `confirmSlugChange: true` after user agreement.

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

All Ignix 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?