Skip to main content
Glama
Brandcode-Studio

brandsystem-mcp

by Brandcode-Studio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Clarify brand values

brand_clarify

Resolve ambiguous brand values interactively by passing a clarification ID and user answer—hex color, role, font, or yes/no—to update brand identity and return the remaining clarification count.

Instructions

Resolve an ambiguous brand value interactively. After brand_compile, some values need human confirmation — wrong primary color, unknown font, unassigned color roles. Pass the clarification item ID and the user's answer (hex color, role name, font name, or 'yes'/'no'). Supports natural language: 'the purple one is accent' or '#5544f2 is secondary'. Returns updated identity and remaining clarification count.

Input Schema

NameRequiredDescriptionDefault
idYesClarification item ID from needs-clarification.yaml (e.g. 'clarify-1')
answerYesThe user's answer: a hex color (#ff0000), a role name (primary, secondary, accent, neutral, surface, text, action, tint, overlay, border, gradient, highlight), a font name, 'yes'/'no', or natural language ('the purple one is accent, the pink transparents are tint')

Output Schema

NameRequiredDescriptionDefault
_metadataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.17.0
    • changedOutput schema / additionalProperties
      Previous value: -trueNew value: +{}
    • changedOutput schema / properties / _metadata / additionalProperties
      Previous value: -trueNew value: +{}
  2. Addedv0.14.1
  3. Removedv0.12.0
  4. Changed1 schema field changedv0.11.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "_metadata": {
+      "additionalProperties": true,
+      "properties": {
+        "next_steps": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "what_happened": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "what_happened",
+        "next_steps"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "_metadata"
+  ],
+  "type": "object"
+}
  5. First observedv0.5.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag this as a non-readonly, non-idempotent mutation, and the description adds genuinely new context: it is a human-in-the-loop step, it consumes a clarification item ID, and it returns updated identity plus remaining count. It does not say what happens on an invalid or already-answered item, which is the main remaining gap.

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 purpose, then prerequisites, then parameter forms, then return. Four sentences, all functional, though the answer-format sentence partly duplicates the schema and could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no elaboration, and the description correctly avoids dwelling on them beyond a one-line summary. Prerequisite state and input flexibility are covered; only error and idempotency behavior for repeat answers is unstated.

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% and the description's list of accepted answer forms (hex, role name, font, yes/no, natural language) restates what the schema already documents, including the identical example style. Baseline 3 is appropriate — no net new parameter meaning is added.

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 specific verb and resource ('resolve an ambiguous brand value interactively') and immediately scopes it to the post-brand_compile state, which separates it from compile/status/report siblings. An agent knows exactly what this does without opening the schema.

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?

The prerequisite is explicit ('after brand_compile, some values need human confirmation') and the triggering conditions are enumerated (wrong primary color, unknown font, unassigned color roles). It lacks an explicit 'do not use if…' or a named alternative, so it stops short of full when/when-not coverage.

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

Deploy Server

Other Tools