easysociable-mcp

Update brand

update_brand

Patch an existing brand's colors, typography, logo, or metadata by brandId. Requires baseRevision to prevent overwrite races and preserves unspecified tokens.

Instructions

Patch visual styles, typography, or metadata of an existing Brand by brandId. Call after get_brand to modify palette or fonts. Do NOT use to create new brands (use create_brand) or to delete (use delete_brand). Requires baseRevision for optimistic concurrency locking to prevent overwrite races; on revision mismatch returns 409 Conflict. Safe partial patch: unspecified styling tokens are preserved. Returns updated Brand with incremented revision.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Updated brand name.
`colors`	No	Updated color palette tokens.
`handle`	No	Updated social handle.
`brandId`	Yes	The unique identifier of the brand to update.
`typography`	No	Updated typography configuration.
`displayName`	No	Updated display name.
`logoAssetId`	No	Updated logo asset ID.
`baseRevision`	Yes	Current revision number for optimistic concurrency lock. Must match latest revision from get_brand.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`brandId`	No	Brand ID.
`revision`	No	Incremented revision number.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.17Oct 5, 2026

changedInput schema / properties / baseRevision / description

Previous value: -"Current revision number for optimistic concurrency lock."New value: +"Current revision number for optimistic concurrency lock. Must match latest revision from get_brand."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "brandId": {
+      "description": "Brand ID.",
+      "type": "string"
+    },
+    "revision": {
+      "description": "Incremented revision number.",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

Changed8 schema fields changedv0.1.16Oct 5, 2026
- addedInput schema / properties / baseRevision / description
```
Added value: +"Current revision number for optimistic concurrency lock."
```
- addedInput schema / properties / brandId / description
```
Added value: +"The unique identifier of the brand to update."
```
- addedInput schema / properties / colors / description
```
Added value: +"Updated color palette tokens."
```
- addedInput schema / properties / displayName / description
```
Added value: +"Updated display name."
```
- addedInput schema / properties / handle / description
```
Added value: +"Updated social handle."
```
- addedInput schema / properties / logoAssetId / description
```
Added value: +"Updated logo asset ID."
```
- addedInput schema / properties / name / description
```
Added value: +"Updated brand name."
```
- addedInput schema / properties / typography / description
```
Added value: +"Updated typography configuration."
```
First observedv0.1.13Oct 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description adds crucial context beyond them: the optimistic concurrency mechanism (requires baseRevision), the specific 409 Conflict response on revision mismatch, and the safe partial-patch behavior preserving unspecified tokens. These details are essential for correct call sequencing and error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and scope, followed by usage guidance, exclusions, behavioral details, and return value, all in efficient sentences with no wasted words. Every sentence adds distinct value.

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?

Despite the tool having an output schema (so return values need not be explained), the description still adds critical context about concurrency, error handling, and partial update semantics. Combined with the schema and annotations, an agent has everything needed to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema fully documents all eight parameters. The description adds meaningful semantics for baseRevision (concurrency lock, must match latest revision) and the partial-patch behavior, but does not provide additional syntax or format details for the updateable fields beyond what the schema already lists.

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 states a specific verb (Patch) and resource (visual styles, typography, or metadata of an existing Brand), and explicitly names sibling tools create_brand and delete_brand to distinguish the scope. An agent can immediately tell this is a partial update operation, not creation or deletion.

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 provides explicit when-to-use guidance ('Call after get_brand to modify palette or fonts') and clear exclusions ('Do NOT use to create new brands... or to delete'), naming the alternative tools for each excluded case. This fully routes the agent to the correct tool.

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