Widely

Upload a white-label brand image

upload_platform_brand_file

Stores one brand image on this swift_platform account and returns its file id and public URL. purpose is mark, mark_dark, icon, or favicon. Send exactly one of content_base64 or source_url. source_url is an https address this server can fetch. filename and content_type must match the bytes. Allowed types are svg, png, jpg, and webp. svg is at most 256 KB. png, jpg, and webp are at most 2 MB. An SVG is cleaned so it has no script and no external reference. Pass the returned file id to set_platform_app_settings. Omitted confirm checks the file and returns a preview. It does not store the file. True stores it. The same idempotency_key returns the first file instead of storing another. The file is stored on the connected account only. An account id in the arguments is ignored.

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": {
      "purpose": "<purpose>",
      "filename": "<filename>",
      "content_type": "<content_type>"
    },
    "name": "upload_platform_brand_file"
  }
}

Input Schema

Name	Required	Description
`confirm`	No	Omitted returns a preview on every client. True stores the file.
`purpose`	Yes	Where this image is used. mark_dark is the mark on a dark background.
`filename`	Yes	Name ending in .svg, .png, .jpg, .jpeg, or .webp.
`source_url`	No	https URL of the file. Omit when content_base64 is set.
`content_type`	Yes	image/svg+xml, image/png, image/jpeg, or image/webp.
`content_base64`	No	File bytes as base64. Omit when source_url is set.
`idempotency_key`	No	Repeats the same stored file instead of storing another.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare write/open-world/non-destructive; the description adds real behavior the annotations cannot: hard size ceilings per format (256 KB SVG, 2 MB raster), SVG sanitization removing script and external references, a preview-only mode, and idempotency-key deduplication semantics that qualify the idempotentHint=false flag. The note that an account id in the arguments is ignored further prevents a misfire.

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?

Starts with the outcome and return values, then moves through format rules, sanitization, and the confirm preview, so the most decision-relevant facts are front-loaded. The style is telegraphic sentence fragments, which reads terse but wastes little; a couple of lines restate schema-documented facts.

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 7-parameter write tool with no output schema, it covers return shape (file id and public URL), storage target (connected account only), constraints, preview-vs-commit, and deduplication. Nothing an agent needs to call it safely and correctly 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 100%, so 3 is the baseline, but the description earns more by stating the mutual exclusion of content_base64 and source_url, that source_url must be an https address the server can fetch, that filename and content_type must match the actual bytes, and the allowed format set. These are cross-parameter constraints the per-field schema text does not express.

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: 'Stores one brand image on this swift_platform account and returns its file id and public URL.' It names the accepted purpose values and the downstream consumer (set_platform_app_settings), so an agent knows exactly what the tool produces and where the artifact goes.

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 explicit operational routing: omitted confirm previews and does not store, true stores, and the same idempotency_key returns the existing file. It also directs the agent to pass the returned file id to set_platform_app_settings. It stops short of naming when to prefer a different upload path (e.g. crm_attach_image), so it is strong context rather than a full alternatives map.

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.