Skip to main content
Glama

Change how the accessibility widget looks and which profiles it offers

set_widget_appearance
DestructiveIdempotent

Use this when the user wants the Inclusify widget on their site to look different — match brand colour, move it off something it covers, change its size or icon — or to change which accessibility PROFILES it offers visitors. WRITES to this website's Inclusify configuration, never to the site's code or theme: it changes what the widget bundle renders. Takes effect within about a minute; the edge cache is purged as part of the change. Every setting is optional and anything you leave out is left exactly as it is, so you can change one without knowing the others. This REQUIRES CONFIRMATION — call without "confirm" first, show the user the preview, then call again with the token once they agree — because the result is visible to that site's real visitors. Removing an accessibility profile is the consequential part: it takes an accommodation away from visitors who may be relying on it, so the preview names each one. Note that "enabledProfiles" is a COMPLETE REPLACEMENT LIST, not an addition — whatever you pass becomes the whole set, so include the ones already on that should stay on. The account owner is emailed a record with a link to undo it. Needs the STARTER plan or above, matching the panel. Shopify-billed stores and Wix-billed sites cannot use this at all — they customise the widget from the Shopify app and the Wix app respectively. To turn the widget off entirely, use set_widget_enabled instead. One setting here needs more than Starter: "hideBranding", which removes the Inclusify wordmark from the widget's footer, needs the ENTERPRISE plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoLeave this out on the first call to get a preview of exactly what would change, plus a confirmation token. Call again with the same arguments and that token to apply the change. The token lasts 10 minutes and works once.
websiteYesThe website domain as registered in Inclusify, e.g. "example.com".
languageNoWidget interface language. Anything other than English needs a plan with more than one language.
positionNoWhich corner the widget button sits in. HIDDEN removes the floating button entirely, leaving only a trigger element or the keyboard shortcut to open the panel.
triggerIconNoWhich icon the button shows.
triggerSizeNoButton size in pixels, 40 to 80.
hideBrandingNoWhether to remove the Inclusify wordmark from the bottom of the widget panel. ENTERPRISE ONLY; on any other plan this is refused rather than quietly ignored. It removes our wordmark and its link and nothing else: the widget cannot be rebranded with the customer's own logo or name, the floating button keeps its accessibility glyph (that is a standard icon visitors look for, not branding, and its colour and size are separate settings here), and the link to the customer's own accessibility statement is unaffected.
primaryColorNoSix-digit hex, e.g. "#0066ff". The widget button and accents use it.
showOnMobileNoWhether the widget appears on small screens.
enabledProfilesNoThe accessibility profiles offered to visitors, as a complete replacement list — whatever you pass becomes the whole set, so include the ones already on that should stay on. Removing one takes that accommodation away from visitors using it.
triggerElementIdNoThe id of an element on the CUSTOMER'S OWN site that opens the widget — usually a footer or menu link they have styled themselves, e.g. "footer-accessibility". On every page where that element exists the floating button is not rendered, so their link becomes the only visible way in; on pages where it is missing the floating button comes back, so the widget is never unreachable. An element id, NOT a CSS selector, and without the leading "#". Pass null to remove it and go back to the floating button. Setting this does not put the element on their site — they add the id to their own theme; if you have not confirmed the element exists, say so rather than assuming.
hideForeverEnabledNoWhether visitors get a "don't show again" option. Needs the plan that includes it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / position / description
      Previous value: -"Which corner the widget button sits in."New value: +"Which corner the widget button sits in. HIDDEN removes the floating button entirely, leaving only a trigger element or the keyboard shortcut to open the panel."
    • changedInput schema / properties / position / enum
      Previous value: -[
      -  "BOTTOM_RIGHT",
      -  "BOTTOM_LEFT",
      -  "TOP_RIGHT",
      -  "TOP_LEFT"
      -]New value: +[
      +  "BOTTOM_RIGHT",
      +  "BOTTOM_LEFT",
      +  "TOP_RIGHT",
      +  "TOP_LEFT",
      +  "HIDDEN"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / hideBranding
      Added value: +{
      +  "description": "Whether to remove the Inclusify wordmark from the bottom of the widget panel. ENTERPRISE ONLY; on any other plan this is refused rather than quietly ignored. It removes our wordmark and its link and nothing else: the widget cannot be rebranded with the customer's own logo or name, the floating button keeps its accessibility glyph (that is a standard icon visitors look for, not branding, and its colour and size are separate settings here), and the link to the customer's own accessibility statement is unaffected.",
      +  "type": "boolean"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / language / enum
      Previous value: -[
      -  "en",
      -  "es",
      -  "fr",
      -  "de",
      -  "it",
      -  "pt",
      -  "nl",
      -  "ja",
      -  "zh"
      -]New value: +[
      +  "en",
      +  "af",
      +  "am",
      +  "ar",
      +  "hy",
      +  "az",
      +  "eu",
      +  "bn",
      +  "bg",
      +  "my",
      +  "ca",
      +  "zh",
      +  "zh-TW",
      +  "hr",
      +  "cs",
      +  "da",
      +  "nl",
      +  "en-GB",
      +  "et",
      +  "tl",
      +  "fi",
      +  "fr",
      +  "fr-CA",
      +  "ka",
      +  "de",
      +  "el",
      +  "gu",
      +  "he",
      +  "hi",
      +  "hu",
      +  "id",
      +  "ga",
      +  "it",
      +  "ja",
      +  "kn",
      +  "km",
      +  "ko",
      +  "ku",
      +  "lo",
      +  "lv",
      +  "lt",
      +  "ms",
      +  "ml",
      +  "mr",
      +  "ne",
      +  "no",
      +  "fa",
      +  "pl",
      +  "pt",
      +  "pt-BR",
      +  "pa",
      +  "ro",
      +  "ru",
      +  "sr",
      +  "si",
      +  "sk",
      +  "sl",
      +  "es",
      +  "es-MX",
      +  "sw",
      +  "sv",
      +  "ta",
      +  "te",
      +  "th",
      +  "tr",
      +  "uk",
      +  "ur",
      +  "vi",
      +  "cy",
      +  "xh",
      +  "zu"
      +]
  4. Changed1 schema field changed
    • addedInput schema / properties / triggerElementId
      Added value: +{
      +  "description": "The id of an element on the CUSTOMER'S OWN site that opens the widget — usually a footer or menu link they have styled themselves, e.g. \"footer-accessibility\". On every page where that element exists the floating button is not rendered, so their link becomes the only visible way in; on pages where it is missing the floating button comes back, so the widget is never unreachable. An element id, NOT a CSS selector, and without the leading \"#\". Pass null to remove it and go back to the floating button. Setting this does not put the element on their site — they add the id to their own theme; if you have not confirmed the element exists, say so rather than assuming.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  5. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond annotations: it states the tool WRITES to configuration, never code/theme; notes a ~1 minute cache purge; explains the two-step confirm protocol and its visibility to real visitors; describes the consequential removal of profiles; highlights the complete-replacement-list semantics; and mentions the emailed undo link. This provides substantial context on top of the destructiveHint/idempotentHint annotations.

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 every sentence carries necessary operational information. It is front-loaded with the primary use case and then covers confirmation, side effects, plan limits, and exclusions. A slight deduction for density: it could be more scannable with bullet points, but no sentence is wasted.

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 12-parameter write tool with no output schema and substantial side effects, the description explains what it changes, how confirmation works, what happens to the cache, who is notified, what plan requirements exist, and which platforms are excluded. It also clarifies the undo mechanism via email. An agent has everything needed to call this correctly.

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?

Even though schema description coverage is 100%, the description adds essential semantics for multiple parameters: the enabledProfiles replacement-list warning, position HIDDEN behavior, triggerElementId requirements (not a CSS selector, null meaning), hideBranding enterprise-only logic, language plan constraints, and the confirm token flow. This materially helps an agent use parameters correctly.

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+resource: 'Use this when the user wants the Inclusify widget on their site to look different — match brand colour, move it off something it covers, change its size or icon — or to change which accessibility PROFILES it offers visitors.' It clearly distinguishes from the sibling `set_widget_enabled` by saying 'To turn the widget off entirely, use set_widget_enabled instead.'

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?

The description gives explicit when-to-use criteria ('Use this when...'), explicitly routes to the alternative tool for disabling, and provides plan restrictions (STARTER required, Shopify/Wix excluded, hideBranding needs ENTERPRISE). It also details the required confirmation workflow, leaving no ambiguity about how to invoke the tool safely.

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.