Widely

Save white-label app settings

set_platform_app_settings

DestructiveIdempotent

Saves the app name, colours, public hostnames, shared app id, icon, mark, optional dark mark, and favicon file ids, support contacts, and the MCP name and host on this swift_platform account. File ids come from upload_platform_brand_file. Settings are stored on the app config the apps already read. Omitted confirm returns a preview and does not save. A field left out stays as it is. mark_dark_file_id is optional. Leaving it out keeps the current mark on every background. A file id from another account is refused. An app id or hostname already used by another company is refused. take_over true, with confirm, retires active records owned by this account's parent and moves that app id or hostname. The preview lists those records and does not save. group_id is the id returned by create_platform_app when this account has more than one app.

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": "set_platform_app_settings"
  }
}

Input Schema

Name	Required	Description
`mcp`	No	Connector name and host. A blank name or host is filled from this app.
`name`	No
`colours`	No	primary_color, background, and text as #RRGGBB.
`confirm`	No	Omitted returns a preview on every client. True saves.
`support`	No	name, email, phone, url, public_host, terms_url, privacy_url.
`group_id`	No	App id from create_platform_app. Omit when there is one app.
`hostnames`	No	Public hosts with no scheme or port. The first is the primary web host.
`take_over`	No	Omitted refuses an app id or hostname another account already uses. True with confirm retires records owned by this account's parent and moves that app id or hostname. A preview lists those records.
`legal_name`	No
`icon_file_id`	No	File id from upload_platform_brand_file with purpose icon.
`mark_file_id`	No	File id from upload_platform_brand_file with purpose mark.
`shared_app_id`	No	One id for Android, iOS, and web, such as ai.example.app.
`favicon_file_id`	No	File id from upload_platform_brand_file with purpose favicon.
`mark_dark_file_id`	No	Optional file id from upload_platform_brand_file with purpose mark_dark. Used on a dark background. Omitted leaves the current mark unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / mcp

Added value: +{
+  "description": "Connector name and host. A blank name or host is filled from this app.",
+  "properties": {
+    "host": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed4 schema fields changedNov 9, 2026

addedInput schema / properties / favicon_file_id / description

Added value: +"File id from upload_platform_brand_file with purpose favicon."

addedInput schema / properties / icon_file_id / description

Added value: +"File id from upload_platform_brand_file with purpose icon."

addedInput schema / properties / mark_dark_file_id

Added value: +{
+  "description": "Optional file id from upload_platform_brand_file with purpose mark_dark. Used on a dark background. Omitted leaves the current mark unchanged.",
+  "type": "string"
+}

addedInput schema / properties / mark_file_id / description

Added value: +"File id from upload_platform_brand_file with purpose mark."

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / take_over

Added value: +{
+  "description": "Omitted refuses an app id or hostname another account already uses. True with confirm retires records owned by this account's parent and moves that app id or hostname. A preview lists those records.",
+  "type": "boolean"
+}

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (destructive, idempotent, not read-only), it discloses that omitted fields are preserved, that a preview lists takeover records without saving, that file ids from another account are refused, and that app ids/hostnames used by another company are refused. This is exactly the failure-and-side-effect context an agent needs before a destructive write.

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 payload, then preview/confirm behavior, then refusals, then takeover, then group_id — a sensible risk-ordered structure. There is some mild redundancy (mark_dark_file_id's optionality and take_over's semantics are each stated twice, echoing the schema), which keeps it from a 5.

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 14-parameter, nested-object, destructive tool with no output schema, the description covers the preview/save distinction, field-preservation default, validation refusals, takeover consequences, and multi-app disambiguation. Nothing critical to calling it safely is 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 coverage is 86%, so the schema already carries most parameter meaning; the description still adds non-obvious semantics — mark_dark_file_id being optional and retaining the current mark, group_id originating from create_platform_app, and take_over's interaction with confirm and parent-owned records. It adds real value but does not cover every field (e.g. legal_name, shared_app_id format nuances).

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?

Opens with a specific verb and resource ('Saves the app name, colours, public hostnames, shared app id, icon, mark...') bound to a named account scope ('on this swift_platform account'), and it names the companion tools (upload_platform_brand_file, create_platform_app) that feed it, so an agent can place it precisely relative to siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational guidance: omit confirm to preview, take_over true with confirm to take over, group_id only when the account has more than one app. It stops short of saying when to prefer this over sibling setters like crm_set_branding or set_platform_modules, so a 4 rather than a 5.

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

All Widely 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.