Public assessment

ejwhite7/brandkit-mcp (brandkit-mcp)

brandkit-mcp · v2.1.0 · scanned Aug 2, 2026

What changed in the harness

Selection accuracy 92→94, token cost up 14%, unconfirmed writes 100%→100%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

30.0 / 30

30.0 out of 30

02Legibility

20.6 / 30

20.6 out of 30

03Economics

19.9 / 20

19.9 out of 20

04Discoverability

16.8 / 20

16.8 out of 20

Highest-impact fix

Estimated gain +1 point

Rewrite 11 underspecified tool descriptions

State each tool's behavior, explain every parameter, and declare return semantics, prioritizing tools exercised by failed selection tasks.

Description evidence

Defects and rewrites.

11 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`get_brand_overview`	no_return_description	Return a JSON summary of the brand atomic system: brand name, whether a magic_trick.md taste primer exists, counts of inventoried assets/components/tokens, available contexts (base/web/product), and the full list of v2 tool names.
`get_colors_and_type`	params_unexplained	Return colors and typography as CSS custom properties from agent/visual/colors_and_type.css. Optional 'context' parameter (base \| web \| product, default base) selects which artifact override to read the values from.
`get_assets`	params_unexplained	Return logos and other binary assets from agent/visual/assets/, replacing v1 get_logos + get_textures. Optional 'context' parameter (base \| web \| product, default base) scopes which context's asset set is returned.
`get_fonts`	params_unexplained	Return font faces declared in agent/visual/fonts/, including binary font files and an optional fonts.yaml manifest. Optional 'context' parameter (base \| web \| product, default base) scopes which context's font set is returned.
`get_components`	params_unexplained	Return UI component specifications from agent/visual/components/. Optional 'context' parameter (base \| web \| product, default base) filters components to that context, and optional 'name' filters to a single component by name.
`get_tokens`	params_unexplained	Return design tokens from agent/visual/tokens/ specimens. Optional 'context' parameter (base \| web \| product, default base) scopes which context's tokens are returned; optional 'format' parameter (json \| css \| scss \| tailwind \| w3c, default json) sets the output format; optional 'type' filters tokens by type (e.g. color, font, radius, spacing).
`get_motion`	params_unexplained	Return the motion system as parsed motion.json tokens plus the raw motion.css text. Optional 'context' parameter (base \| web \| product, default base) scopes which context's motion files are returned.
`get_css`	params_unexplained	Return raw CSS text from agent/visual/colors_and_type.css and agent/visual/motion/motion.css. Required by the API but effectively optional via default, the 'context' parameter (base \| web \| product, default base) selects which context's CSS files are returned.
`search_brand`	params_unexplained no_return_description	Run a case-insensitive full-text substring search for 'query' across all brand atomic system content (verbal docs, magic_trick, components, tokens, assets, and CSS files), returning matching entries capped at the 'limit' parameter (default 20) with their source location and matched snippet.
`validate_usage`	params_unexplained no_return_description	Validate that the provided HTML or CSS 'snippet' (type set via the 'format' parameter, html \| css, default css) uses brand design tokens rather than literal values and only references known components, returning a list of validation issues found (or confirmation that none were found).
`get_context_diff`	params_unexplained no_return_description	Diff two brand contexts across colors_and_type custom properties, components, and tokens, returning the added/removed/changed differences. 'a' and 'b' select the two contexts to compare (base \| web \| product, defaults web and product respectively).

Selection evidence

Confusable tool pairs.

32 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`get_positioning`	`get_messaging`	medium	Both are verbal brand docs (positioning vs messaging) with heavily overlapping purpose descriptions; a task like 'get the brand's core message' could plausibly be routed to either.
`get_positioning`	`get_differentiation`	medium	Positioning and differentiation are conceptually related (how the brand stands apart) and share nearly identical descriptions/schemas, so a request about 'what makes the brand unique' could match either.
`get_messaging`	`get_differentiation`	low	Both are verbal docs with similar templated descriptions but messaging and differentiation are semantically distinct enough that confusion is less likely except for vague prompts.
`get_positioning`	`get_voice`	low	Both verbal docs share the same template but voice (tone/style) is fairly distinct from positioning (market stance), reducing genuine ambiguity.
`get_messaging`	`get_voice`	low	Similar templated descriptions but messaging content vs voice/tone are distinguishable in most task phrasings.
`get_differentiation`	`get_voice`	low	Shared boilerplate description but differentiation and voice serve clearly different purposes, limiting real confusion.
`get_concepts`	`get_voice`	low	Both are verbal docs with taste primers but 'creative concepts' vs 'voice' are distinct enough that only very vague prompts would confuse them.
`get_differentiation`	`get_concepts`	low	Shared template wording but differentiation (competitive stance) and concepts (creative directions) address different tasks.
`get_messaging`	`get_concepts`	low	Similar description structure but messaging vs creative concepts are distinguishable for most natural-language requests.
`get_positioning`	`get_concepts`	low	Shared boilerplate but positioning and concepts serve different purposes, limiting confusion to only very generic prompts.
`get_assets`	`get_fonts`	medium	Both return binary visual files scoped by context; a request like 'get the brand's visual files' or 'get the logo fonts' could plausibly be misrouted between assets and fonts.
`get_components`	`get_css`	medium	Both relate to UI/visual specs and share context param; a task like 'get the component styles' could ambiguously target either components (specs) or css (raw styles).
`get_fonts`	`get_css`	low	Both are visual/context-scoped but fonts (binary font files) and css (raw stylesheet text) are fairly distinguishable outputs.
`get_assets`	`get_components`	low	Both are visual context-scoped tools but assets (binary logos/images) vs components (UI specs) address different needs.
`get_assets`	`get_css`	low	Both visual/context-scoped but assets are binary files vs css raw text, generally distinguishable.
`get_assets`	`get_motion`	low	Both return visual system data but assets (static binaries) vs motion (animation tokens) differ enough in purpose.
`get_audience`	`get_components`	low	Little semantic overlap beyond shared generic tokens; audience is a verbal/yaml doc while components are visual specs.
`get_audience`	`get_css`	low	Minimal genuine overlap; audience data and raw CSS serve very different purposes.
`get_audience`	`get_fonts`	low	Both context/yaml-adjacent but audience (demographic definition) and fonts (typeface files) aren't plausibly confused.
`get_audience`	`get_motion`	low	Shared generic tokens only; audience yaml vs motion tokens are semantically unrelated.
`get_components`	`get_motion`	low	Both visual/context-scoped but components (UI specs) and motion (animation system) are distinct enough to avoid real confusion.
`get_fonts`	`get_motion`	low	Both context-scoped visual tools but fonts and motion address unrelated asset types.
`get_brand_overview`	`get_tokens`	low	Only the word 'get' is shared; overview is a summary tool while tokens returns design token values, unlikely to be confused.
`get_brand_overview`	`search_brand`	low	Both touch the whole brand system but overview (static summary) vs search (query-driven lookup) are functionally distinct enough for most prompts.
`get_colors_and_type`	`get_tokens`	medium	Both return color/typography-related data scoped by context; a request like 'get the brand colors' could plausibly route to either the CSS custom properties tool or the design tokens tool.
`get_magic_trick`	`get_tokens`	low	No real semantic overlap; magic_trick is a taste primer document while tokens are design token values.
`get_tokens`	`get_context_diff`	low	Both involve 'token'/context concepts but tokens returns values for one context while context_diff compares two; distinguishable for most tasks.
`get_brand_overview`	`get_colors_and_type`	low	Minimal overlap; overview is a system summary, colors_and_type returns specific CSS properties.
`get_brand_overview`	`get_context_diff`	low	Both touch on 'contexts' but overview lists them while diff compares two specific contexts; low ambiguity.
`get_colors_and_type`	`get_context_diff`	low	Both involve colors/contexts but one returns properties and the other diffs across contexts; distinguishable for typical requests.
`get_magic_trick`	`get_colors_and_type`	low	No meaningful semantic overlap between the taste primer doc and CSS color/type properties.
`get_magic_trick`	`get_context_diff`	low	No meaningful semantic overlap between the taste primer doc and a context comparison tool.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard