Skip to main content
Glama

Rebbel

by io.rebbel
OverviewDiscussionsAdmin

Update brand guide

update_brand_guide

Edits specific lines of a brand guide directly, the way the dashboard's inline edit does: replace, remove or add a line in doList, dontList, limitations, offers, voice.toneRules, voice.examples, imagery.doList or imagery.dontList; set identity.tagline, identity.mission, identity.description or imagery.styleDescription; add, update or remove a capability by name. A line to replace or remove is named by its exact current text and must match exactly one line, otherwise nothing is changed and the nearest lines are listed. All-or-nothing, and every line you don't name stays exactly as it was. Returns what would change and saves nothing unless apply is true, so call it once without apply, show the owner the changes, then again with apply true. Pass expectedVersion (from get_brand_guide) so a guide edited elsewhere in the meantime is refused. Does not approve the guide: an approved guide stays approved and is marked edited after approval. When the edit touches limitations, identity, offers or capabilities it also lists other guide lines that contradict it (advisory, nothing is changed for you); this uses a small amount of the brand's generation budget, and checkConsistency false skips it. Not for palette, logos, fonts, personas or a full rewrite — use set_brand_guide_typography, set_brand_logo or regenerate_brand_guide_section for those.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
applyNoDefault false: return exactly what would change (before/after for each operation) and write nothing. Pass true to save it.
brandIdYesThe brand's id, from list_brands.
guideIdYesThe guide's id, from get_brand_guide.
operationsYesThe edits, applied in order. All or nothing: if any operation can't be applied exactly, none are and every problem is listed.
expectedVersionNoThe guide's version (from get_brand_guide) that you read these lines from. Refused if the guide has changed since — e.g. someone edited it in the dashboard.
checkConsistencyNoDefault true. When the edit touches limitations, identity, offers or capabilities, also check the rest of the guide for lines that now contradict it and list them as warnings — advisory only, nothing is changed automatically. Pass false to skip.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare it is non-readonly and non-destructive but say nothing about transactionality or side effects; the description supplies all-or-nothing semantics, exact-match refusal that changes nothing, dry-run-by-default, version-conflict refusal, approval state preservation, and that consistency checking consumes generation budget. This is rich context well beyond 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 core action and its scope, then layers workflow, safety and exclusions, with every sentence carrying distinct information. It is long and dense, but the length is justified given the tool's complexity; only minor tightening is possible.

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 multi-operation mutation tool with no output schema, it covers dry-run behavior, version guarding, all-or-nothing failure, approval implications, budget cost, and alternative tools. 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 operational meaning: how 'match' behaves (must match exactly one line or nothing changes and nearest lines are returned), the apply/expectedVersion sequencing rationale, and the checkConsistency cost. It largely mirrors the schema's own rich field docs, keeping it below a 5.

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?

States a precise verb and resource ('edits specific lines of a brand guide') and enumerates the exact editable sections, operations and fields. It also names the siblings it is not (set_brand_guide_typography, set_brand_logo, regenerate_brand_guide_section), so an agent can route without opening any schema.

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?

Gives an explicit workflow ('call it once without apply, show the owner the changes, then again with apply true'), the prerequisites (expectedVersion from get_brand_guide), and clear exclusions mapped to alternative tools. When-to-use and when-not-to-use are both spelled out.

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

All Rebbel toolsInspect
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