brandsystem-mcp

Brandcode Studio auth

brand_brandcode_auth

Destructive

Activate a Brandcode Studio connection to save and push brands, with status, login, manual token, and logout modes for managing authentication.

Instructions

Activate Brandcode Studio connection for saving and pushing brands. Preferred mode: "activate" displays a short code (e.g. BRAND-7K4X) for the user to enter at brandcode.studio/activate — no copy-paste of tokens needed. Also supports: "status" (check auth), "login" (magic link fallback), "set_key" (manual token), "logout" (clear credentials). Use when the user wants to save their brand to Studio or says "activate", "connect to Brandcode", or "save my brand online". NOT needed for extraction, preview, or brand_check — those work without auth.

Input Schema

Name	Required	Description
`key`	No	Session token from magic link verification. Required when mode="set_key". Format: JWT from /api/auth/verify.
`mode`	Yes	Auth action. "activate" (recommended) starts device code flow — displays a short code for the user to enter at brandcode.studio/activate, then polls for completion. No copy-paste needed. "status" checks if authenticated. "login" starts magic link flow (fallback). "set_key" stores token manually. "logout" removes credentials.
`email`	No	Email address for login. Required when mode="login".
`studio_url`	No	Brandcode Studio base URL. Defaults to "https://www.brandcode.studio". Must be a trusted Studio origin; self-hosted/staging origins are added via the BRANDCODE_STUDIO_TRUSTED_ORIGINS environment variable.

Output Schema

Name	Required	Description	Default
`_metadata`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.17.0Oct 25, 2026
Removedv0.13.4Jul 18, 2026

Changed1 schema field changedv0.11.0Jul 17, 2026

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"
+}

Addedv0.9.2May 5, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Goes beyond annotations by explaining the device-code flow (displays a short code like BRAND-7K4X, then polls for completion), that no token copy-paste is required, that login is a magic-link fallback, and that studio_url must be a trusted origin configured via an env var. The one gap is that the 'logout'/credential-clearing and destructiveHint=true side effects are not elaborated on, and the description never references the write/destructive profile the annotations declare.

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 primary action and the preferred mode before the alternatives, and the exclusion sentence is well placed at the end. Some redundancy exists between the prose mode list and the enum descriptions, but no sentence is wasted overall.

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?

With an output schema, full annotation coverage, and 100% schema description coverage, the description supplies the remaining needed context: mode selection strategy, trigger phrases, exclusions, and the trusted-origin constraint. Only the consequences of the destructive 'logout' path are left implicit.

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 description coverage is 100% and the enum descriptions already explain each mode, so the description's mode rundown largely repeats structured data. It adds only light context (the example code format and the preferred/fallback ordering), not new semantics for key, email, or studio_url.

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 ('Activate Brandcode Studio connection for saving and pushing brands') and enumerates the five supported modes. It also explicitly carves out sibling capabilities ('NOT needed for extraction, preview, or brand_check'), so an agent can distinguish it from brand_check, brand_compile, brand_export, etc. without opening a 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 explicit when-to-use triggers ('save their brand to Studio', 'activate', 'connect to Brandcode') and when-not ('NOT needed for extraction, preview, or brand_check'). It also names 'activate' as the preferred mode and positions 'login' as a fallback, which is exactly the routing guidance an agent needs across the 5-value enum.

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

Deploy Server