Foldsquare

Change how a catalog is published

set_publish_options

DestructiveIdempotent

Switch the Publish dialog's options on and off: publish or unpublish (published), the custom URL (slug), what a product click does (clickBehavior), auto-sync, the customer lead form, password protection with its password, search-engine visibility, and the viewer — view mode, theme, background colour, which toolbar buttons show, reading direction, single page, shadows, lighting, flip sound and speed. Options left out are left as they are. What the plan or store allows is applied and listed under applied; the rest comes back under refused, each with its reason — nothing is downgraded silently. The result is the catalog as it now stands. The password is one the merchant chooses; open_publish_settings takes it in a form, without it passing through the chat. published: true publishes without rendering a PDF; publish_catalog does both. When published: true would take a draft live, nothing in the call is applied without confirm: true; the answer lists what would go live under requiresConfirmation — the catalog and its public link — for the merchant to approve, with confirmWith holding the arguments that carry it out. The retail cart needs a Shopify store and its Storefront API token, which is entered in Foldsquare's settings and is not accepted by these tools.

Input Schema

Name	Required	Description
`confirm`	No	true once the merchant has agreed to make a draft public
`options`	Yes	The options to change; omit the rest
`catalogId`	Yes	Catalog id, as returned by list_catalogs

Output Schema

Name	Required	Description
`title`	No
`locked`	No	Options the plan or store does not allow, each with its reason
`status`	No
`applied`	No	The options changed; false when a draft is waiting for the merchant to confirm going live
`catalog`	No
`options`	No	Every Publish dialog option, as set_publish_options takes them
`refused`	No	Options not changed, each with why
`catalogId`	No
`editorUrl`	No
`embedCode`	No
`publicUrl`	No
`published`	No
`shareLink`	No
`viewerUrl`	No
`confirmWith`	No	The arguments that carry the change out once the merchant agrees
`livePreviewUrl`	No
`requiresConfirmation`	No	Present when nothing was changed: the consequences to show the merchant before calling again with confirm: true

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond annotations, it discloses partial-update semantics, plan/store permission handling via `applied` and `refused` with reasons, no silent downgrades, password non-return, and the draft-to-live confirmation flow with `requiresConfirmation` and `confirmWith`. These are material behavioral details an agent needs before invoking a destructive, open-world mutation.

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?

The description is long but mostly earns its length given the many nested options and confirmation behavior. It is front-loaded with purpose and option scope, though the dense single paragraph could be more clearly structured.

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?

For a complex destructive mutation with nested objects and an output schema, the description covers the key gaps: partial updates, permission refusals, confirmation requirements, password handling, and the distinction from sibling publish tools. Nothing essential for correct invocation appears missing.

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 description coverage is 100%, so the schema already documents individual parameters in detail. The description still adds cross-parameter meaning: omitted options remain unchanged, `confirm: true` gates draft publication, and `published: true` has different PDF behavior than publish_catalog.

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 opens with a specific verb and resource: switching the Publish dialog's options on and off, then enumerates the option areas. It also distinguishes this from publish_catalog by noting that `published: true` here does not render a PDF, while publish_catalog does both.

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 routes agents to alternatives: publish_catalog for publishing plus PDF rendering, and open_publish_settings for entering the password via a form rather than through chat. It also states the confirmation requirement when publishing a draft, which is a key conditional before calling.

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

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