dForms

Update the brand kit

update_brand_kit

DestructiveIdempotent

Replace the whole workspace brand kit: a field left out is no longer set by the kit. The kit sent is usually what get_brand_kit returned, with only the requested change. To clear a field, leave it out (logo, primaryColor, background, foreground and customFont also take null); to clear the whole kit, send {}: it then sets nothing. The kit itself is never deleted, as over the REST API. Existing forms keep their look until apply_brand_kit; the workspace link page is styled with the kit, so a live link page shows the change at once. Destructive: it deletes or replaces data, so it is best confirmed with the user first, naming exactly what will change. After an error or a timeout, a read shows whether the change went through, so a blind retry is not needed. Owners and admins only.

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": {
      "kit": "<kit>"
    },
    "name": "update_brand_kit"
  }
}

Input Schema

Name	Required	Description	Default
`kit`	Yes	The whole kit, as get_brand_kit returns it (when it returns null, start from {}). Fields: logo (an image URL, or null; use https, since an http image is blocked on the https form page), clientLogos (up to 24), primaryColor, background (setting it fixes forms to a light or dark look) and foreground (CSS colors or null), fontFamily (figtree, poppins, inter, dm-sans, space-grotesk, manrope, work-sans, fraunces or playfair), customFont, radius (sharp, soft or round), buttonStyle (solid, outline or soft).
`workspace_id`	No	The workspace this call acts in: an id from list_my_workspaces. Required for a person signed in with several workspaces and for staff of this deployment; optional with an API key or with only one workspace.

Output Schema

Name	Required	Description
`kit`	Yes	The brand kit, or null when the workspace has none yet.
`workspace`	Yes	The workspace this call acted in, to compare with the one the user means.
`updated_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint/idempotentHint, but the description adds non-obvious behavior: the kit itself is never deleted (unlike the REST API), link pages restyle instantly while forms do not, and after an error a read reveals whether the change applied so a blind retry is unnecessary. That is materially richer than the annotation set.

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 most important fact (whole-object replacement) and every sentence carries distinct information. It is dense to the point of being run-on in places, but there is little waste to cut without losing behavior detail.

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 destructive, nested-object mutation with an output schema present, the definition covers payload construction, clearing, permissions, side effects on forms and link pages, and error/timeout recovery. Nothing an agent needs to call it 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 the baseline is 3, but the description adds genuine semantics: omitting a field clears it, null is also accepted for several fields, and sending {} clears the whole kit. It does not explain workspace_id, but the schema documents that parameter fully.

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?

"Replace the whole workspace brand kit" names a specific verb (replace, whole-object) and resource, and the replacement semantics are spelled out immediately ("a field left out is no longer set"). This clearly separates it from siblings get_brand_kit, apply_brand_kit and revert_brand_kit without naming them all.

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 tells the agent where the payload comes from ("usually what get_brand_kit returned, with only the requested change") and routes the downstream action to apply_brand_kit ("Existing forms keep their look until apply_brand_kit"). It also adds a usage precondition ("Owners and admins only") and an interaction rule (confirm first, naming what will change).

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

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