A brand-locked MCP server for generating and validating Sample Brand design assets (social posts, quote cards, one-pagers) with spelling correction, palette/typography enforcement, and Illustrator-safe SVG output.
Inspect the server — get_mcp_status (version, runtime paths, capabilities, asset health) and audit_brand_assets (verify required logos/fonts are available).
Fetch brand rules — get_brand_guidelines by section (colors, typography, logo, social, video, policyOutputs, spelling, strictGenerationRules).
Generate social SVGs — create_social_svg with templates policy_alert, statistic, quote, cta, lower_third and variants like navy_poster, petition_push, violet_alert, statistic_card, contrast_cards, quote_post.
Generate quote posts — create_quote_post using approved synthetic speakers (speaker1–speaker8) with mandatory violet emphasis and uncropped embedded portraits.
Materialize one-pagers — create_one_pager writes a working SVG to the local workspace using material_cost_chain or access_barriers templates (no chat truncation).
Build prompts for other models — create_generation_prompt for social, one-pager, video, policy doc, website, or ad outputs.
Validate designs — validate_design_spec (palette, typography, logo, format, draft/final mode).
Validate SVG artifacts — validate_svg_artifact (brand rules + Illustrator-safe SVG 1.1) and validate_illustrator_svg (rejects browser-only features).
QA copy and layout — qa_social_layout corrects spelling and checks copy fits template limits before rendering.
Validate one-pagers — validate_one_pager_file (path-based, preferred) or validate_one_pager_svg (inline markup compatibility).
Run locally or over HTTP — stdio via pnpm start, or HTTP at /mcp (health /healthz) with host allowlisting.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Brand MCP Create a quote post for speaker2 with the quote 'Design is intelligence made visible.'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A standalone Model Context Protocol server for brand-guided design generation, using Sample Brand, a fictional demonstration identity.
The sample identity includes a violet-and-slate palette, original geometric diamond symbols, nine vector logo variants, three photorealistic AI-generated speaker cutouts plus five legacy geometric avatars, and seven social and one-page layout references. Names, roles, quotes, reference copy, statistics, and example.com addresses are demonstration content, not real people or factual claims.
Requires Node.js 22 or 24 and pnpm 11.
pnpm install --frozen-lockfile
pnpm build
pnpm startpnpm start runs the stdio MCP server. See examples/client-config.json and replace the example absolute path with your checkout path. Use the server key sample-brand.
For HTTP on port 8080:
pnpm start:httpThe HTTP endpoint is /mcp; health is /healthz. The default host allowlist contains localhost, loopback addresses, and sample-brand-mcp. Set SAMPLE_MCP_ALLOWED_HOSTS for your deployment. HTTP mode does not expose filesystem materialization or file validation tools. It provides no authentication; configure authentication at your reverse proxy before exposing it beyond your intended audience.
Related MCP server: @forgespace/branding-mcp
Call get_brand_guidelines before generation.
Use create_social_svg, create_quote_post, create_generation_prompt, or local create_one_pager.
Review spelling corrections and validate the result. Resolve final-mode violations.
Social variants: navy_poster, petition_push, violet_alert, statistic_card, contrast_cards, and quote_post. Lower thirds are supported through create_social_svg.
For photographic quote posts, choose speaker1, speaker2, or speaker3. These are original AI-generated fictional people supplied as transparent PNG cutouts. speaker4 through speaker8 retain legacy geometric avatars. No real speaker attribution or portrait is bundled.
One-page templates: material_cost_chain and access_barriers. The tool materializes a clean working SVG into deliverables/. Replace its content and illustration, supply real sources, then validate its exact path using validate_one_pager_file. The populated references are layout demonstrations, not finished factual publications.
Resources use the brand://sample/ namespace. Run get_mcp_status and audit_brand_assets to inspect the running server and asset availability.
data/sample-brand.json: identity, typography, palette, speaker profiles, and generation rules.
assets/manifest.json: asset inventory.
assets/logos/: synthetic SVG logo variants.
assets/quote-people/: transparent photographic PNG cutouts and legacy SVG-wrapped geometric avatars.
assets/post-references/ and assets/one-pager-references/: editable layout references.
src/brand.ts: rendering and validation contracts. Palette and layout changes may also require updates here and in tests.
Local output paths can be configured with SAMPLE_BRAND_WORKSPACE_DIR, SAMPLE_BRAND_OUTPUT_DIR, and SAMPLE_BRAND_ASSET_DIR. This project uses its own package, configuration namespace, and Git history.
Install the supplied fonts before editing generated SVGs in a design application. Open font assets retain their required license and copyright notices under assets/fonts/licenses/.
pnpm check
pnpm test
pnpm smoke
pnpm render:samplesWith the HTTP server running, pnpm smoke:http checks the local endpoint. Set SAMPLE_MCP_URL to test another endpoint. pnpm audit:prod checks production dependencies.
The code remains UNLICENSED; publication does not grant an open-source license. Font licenses are supplied separately.
Check whether required SAMPLE logo and font assets are available for final branded output.
| Name | Required | Description | Default |
|---|---|---|---|
| basePath | No | Optional asset directory. Defaults to SAMPLE_BRAND_ASSET_DIR or ./assets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description only needs to add check-specific context. It does clarify that it checks file availability for SAMPLE logo and font assets, but it does not disclose the result shape or behavior when assets are missing, especially since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence that front-loads the action and resource without filler. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and strong annotations, the description provides enough information to invoke it correctly. The only meaningful gap is the absence of any statement about return values or missing-asset behavior, but this is minor given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, basePath, is fully documented in the schema, including its optionality and default value. The description adds no extra parameter meaning, but with 100% schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Check whether') and a concrete resource ('required SAMPLE logo and font assets'), tied to a clear purpose ('final branded output'). It is not a tautology, but it does not explicitly name or contrast siblings such as validate_design_spec or get_brand_guidelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for final branded output' gives clear context on when this check is appropriate, implying it should be used before producing final branded assets. It does not explicitly mention when not to use it or suggest alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correct and visibly report spelling issues, then create a strict brand-locked prompt for another LLM or image/design model using the corrected request.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| outputType | No | general | |
| includeNegativePrompt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful context about spelling correction, visible reporting, and brand-locking, but it does not explain what 'visibly report' returns, how brand-locking is enforced, or what happens with edge cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and front-loads the correction behavior. The term 'strict brand-locked' is somewhat jargon-heavy but does not bloat the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter descriptions, the definition omits the return format, the meaning of outputType and includeNegativePrompt, and behavior when no spelling issues exist. An agent can call it with the required request, but cannot confidently tailor or interpret the result beyond the basic intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to carry parameter meaning. It only hints that request may contain spelling errors; it says nothing about outputType enum values or includeNegativePrompt, leaving the agent to infer or ignore those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('create') and a specific deliverable ('strict brand-locked prompt'), plus a distinct preprocessing behavior ('correct and visibly report spelling issues'). This distinguishes it from content-generation siblings like create_social_svg and create_quote_post, though 'another LLM or image/design model' is broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as validate_design_spec or create_one_pager. The process language implies that it is for generating prompts from corrected requests, but it does not state conditions, exclusions, or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correct and visibly report spelling issues in the request and supplied copy, then materialize a complete clean SAMPLE one-pager working SVG directly into the shared local workspace. Returns a compact file path and SHA-256 instead of transferring the SVG through chat, preventing resource truncation. Edit that file in place, never append content to the populated visual reference, and validate by path with validate_one_pager_file.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | draft | |
| request | Yes | The policy topic, argument, audience, and evidence the one-pager must communicate. | |
| sources | No | Named source citations for the locked footer source line. At least one is required in final mode. | |
| headline | No | Optional final headline. It must fit the selected reference title slot. | |
| template | No | Use auto unless the request explicitly calls for the material/cost-chain or access/barriers composition. | auto |
| keyMessage | No | Concise closing consumer-choice takeaway for the locked bottom navy panel. | |
| centralObject | No | The physical object, product, device, building, or cutaway composite that should replace the source house/AC illustration. | |
| outputFileName | No | Optional plain SVG file name for the materialized shell. It is always written inside the configured SAMPLE output directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does it well: it discloses that the tool writes to the workspace, returns a file path and SHA-256 instead of inline SVG, prevents resource truncation, and expects in-place editing. Minor gaps remain around overwrite behavior and validation details, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver purpose, return behavior, and usage instructions with little filler. The phrasing is dense and each clause earns its place, though the primary action is slightly buried after the spelling-correction preface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema, the description provides the essential operational context: file materialization, return format, truncation avoidance, and validation path. It does not fully explore template selection or return content, but the high schema coverage and clear sibling reference make the definition reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the parameter schema already documents almost all fields. The description only loosely maps to the 'request' parameter and does not add semantics for mode, template, centralObject, or outputFileName beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the deliverable: a 'complete clean SAMPLE one-pager working SVG' materialized into the shared local workspace. It also names the accompanying spelling-correction behavior and the validation sibling, making the tool's role distinct from other SVG/content tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong post-invocation guidance ('Edit that file in place, never append content... validate by path with validate_one_pager_file'), but it does not state when to prefer this tool over alternatives like create_social_svg or create_generation_prompt. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correct and visibly report spelling issues in the supplied quote, then create a download-ready, Illustrator-safe SVG 1.1 SAMPLE quote post for an approved team member using corrected text. Keeps text and portrait in protected non-overlapping zones, scales portrait prominence proportionally to quote length, contains the full uncropped portrait, embeds it through xlink:href, keeps text editable with packaged installed fonts, verifies the name/title, and always applies Signal Violet emphasis.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | draft | |
| quote | Yes | Exact quote text without surrounding quotation marks. | |
| person | Yes | Synthetic demo speaker. Read brand://sample/quote-people when the user's name or role needs resolving. | |
| emphasis | No | Optional word or short phrase from the quote. The generator highlights one matching meaningful word in Signal Violet; if omitted or invalid, it selects one automatically so emphasis is never missing. | |
| assetBasePath | No | Optional asset directory containing the template, portraits, logo, and fonts. | |
| officialLogoHref | No | Optional approved SAMPLE logo reference. Defaults to the packaged violet wide logo used on dark fields. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations by disclosing many behavioral traits: spelling correction and reporting, protected non-overlapping zones, proportional portrait scaling, full uncropped portrait, xlink:href embedding, editable text with packaged fonts, name/title verification, and Signal Violet emphasis. This gives the agent a rich model of what the tool will do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded and every clause adds a distinct requirement, so the density is justified. The long single sentence is somewhat run-on and could benefit from bullets, but it does not contain fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description conveys the deliverable type, key layout constraints, editable text, embedded portrait, and visible spelling report. It omits explicit return format/path details and the approval workflow, but schema and annotations cover the parameter and safety dimensions well enough for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so most parameter meaning already comes from the schema. The description adds useful context tied to parameters—quote text is corrected, emphasis is always Signal Violet, portrait relates to person—but it does not materially clarify mode, assetBasePath, or officialLogoHref beyond their schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action: correct and visibly report spelling issues, then create a download-ready, Illustrator-safe SVG 1.1 SAMPLE quote post. The verb, resource, and format are all specific, and the 'SAMPLE' plus 'Illustrator-safe SVG' qualifiers distinguish it from generic creation or validation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case—creating a sample quote post for an approved team member—and sets clear expectations such as spelling correction and visible report. However, it never explicitly says when to prefer this over create_social_svg or the validators, nor does it state exclusions or approval prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correct and visibly report spelling issues in all supplied copy, then generate an Illustrator-safe SVG 1.1 SAMPLE artwork from the reference-locked social templates using only corrected text. This is the only supported social-post renderer: never recreate its SVG through a legacy or freeform generator. Outputs use editable packaged SAMPLE fonts, native unscaled headline glyphs, inline vector logos, and xlink:href for embedded rasters. Any PNG preview must be rendered with the packaged files in assets/fonts; never accept a system-font fallback preview. For template=quote, provide person and put the quote in headline; the generator uses reference 5 with a non-overlapping, uncropped, fully embedded approved portrait, verified attribution, and mandatory violet emphasis.
| Name | Required | Description | Default |
|---|---|---|---|
| cta | No | ||
| body | No | ||
| mode | No | draft | |
| kicker | No | ||
| leadIn | No | Optional reference-3 lead-in above the main headline, for example 'TELL YOUR LAWMAKERS:'. Omit to use that reference-locked default. | |
| person | No | Required for template=quote. The approved person whose packaged portrait, full name, and current SAMPLE title will be used. | |
| emphasis | No | Optional exact quote word or phrase to emphasize in Signal Violet. | |
| headline | Yes | ||
| template | No | policy_alert | |
| variation | No | Compatibility field. Reference-locked social outputs preserve variation 0 geometry; choose another styleVariant for genuine layout variety. | |
| styleVariant | No | Optional SAMPLE guide variant. auto maps quote posts to quote_post, petition/lawmaker asks to petition_push, policy alerts to violet_alert, statistics to statistic_card, and most other posts to navy_poster. | auto |
| assetBasePath | No | Optional asset directory used to verify officialLogoHref and default logo assets. | |
| comparisonLeft | No | Optional left-side copy for contrast_cards. Use for the BAD/NO policy position. | |
| comparisonRight | No | Optional right-side copy for contrast_cards. Use for the GOOD/YES policy position. | |
| officialLogoHref | No | Optional href/path for an approved logo file listed in assets/manifest.json. Defaults to a packaged official SVG logo chosen for the background. | |
| includeLogoPlaceholder | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds substantial behavioral detail beyond those: copy is corrected and spelling issues visibly reported, output uses packaged fonts with native unscaled headline glyphs, inline vector logos, xlink:href for rasters, and PNG previews must never use system-font fallback. No statement contradicts the read-only/idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriate for a 16-parameter, no-output-schema tool. It is organized: purpose, exclusivity, output construction details, preview rule, and quote-specific usage. Each section adds information, though the first sentence is slightly overloaded by combining the spell-check behavior with the generation purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and missing output schema, the description covers the essential workflow well: output format, rendering constraints, tool exclusivity, and quote-specific parameter relationships. It does not explain several high-level fields like mode, cta, body, and kicker, but an agent can still correctly invoke the core social-post workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 56%, so the description must compensate for under-documented parameters. It does add useful cross-parameter meaning for quote templates: person is required, the quote belongs in headline, and emphasis is violet. However, several parameters lacking schema descriptions (cta, body, kicker, mode, assetBasePath, includeLogoPlaceholder) remain unexplained by both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('generate') and resource ('Illustrator-safe SVG 1.1 SAMPLE artwork from reference-locked social templates'), and also names the spell-check/report behavior. It explicitly positions itself as 'the only supported social-post renderer' and contrasts with legacy/freeform generators, making it distinguishable from siblings such as create_one_pager or create_quote_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states an explicit exclusivity rule: 'never recreate its SVG through a legacy or freeform generator.' It also gives concrete conditional guidance for template=quote ('provide person and put the quote in headline') and mandates the violet emphasis. This is strong usage direction, including a prohibition against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return SAMPLE brand guidelines from the 2026 guide. Use this before generating any SAMPLE-branded output.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source ('2026 guide') and intended usage, but it does not describe what the returned guidelines contain or how the response varies by section. This is adequate but not behaviorally rich beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core outcome first and no filler. The second sentence adds direct usage guidance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter, read-only, idempotent retrieval tool, the description plus the enum/default schema provides enough to select and invoke it. The lack of an output schema means the response format is not described, but for a brand-guidelines retrieval this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the `section` parameter or explains how values like 'colors', 'typography', or 'all' change the returned guidelines. The enum and default in the schema are self-explanatory, but the description was expected to compensate for missing schema descriptions and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Return') and a specific resource ('SAMPLE brand guidelines from the 2026 guide'). It also positions the tool as a prerequisite for generation, which distinguishes it from the create/validate siblings. However, it does not explicitly contrast it with a close sibling like audit_brand_assets, so it stops just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this before generating any SAMPLE-branded output' is explicit when-to-use guidance. The description does not list alternatives or edge cases, but for a simple read-only retrieval tool the primary usage condition is clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the live SAMPLE Brand MCP version, runtime paths, core capabilities, and packaged asset health. Use this to confirm a client loaded the latest rebuilt server after an update.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about the 'live' nature of the response and its role in verifying a rebuilt server load, but it does not disclose output format or potential variability. This is modest added value on top of strong annotations, matching a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the tool's output scope and the second sentence provides the operational use case. It is front-loaded and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with thorough annotations, the description covers the essential information: what will be reported and why to use it. It does not describe the response format, but given the low complexity and absence of an output schema, this is a minor gap rather than a missing requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so parameter semantics are not a concern; the baseline of 4 applies. The description does not need to explain parameters and does not introduce any confusion about how to call the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Report' and names the exact resource: SAMPLE Brand MCP version, runtime paths, core capabilities, and packaged asset health. This clearly distinguishes it from the sibling design-validation and generation tools, which operate on brand assets and files rather than server status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the intended use case: 'Use this to confirm a client loaded the latest rebuilt server after an update.' This gives the agent clear context for when to invoke the tool, though it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correct and visibly report spelling issues, then check whether the corrected social or lower-third copy fits SAMPLE layout limits before generating SVG.
| Name | Required | Description | Default |
|---|---|---|---|
| cta | No | ||
| body | No | ||
| mode | No | final | |
| headline | Yes | ||
| template | No | policy_alert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows it is a safe read operation. The description adds that it corrects spelling and checks layout, which is useful context, but it does not disclose any unexpected side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs multiple steps, but it is somewhat clunky and could be split into clearer parts. It is not excessively long but not optimally structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with no schema descriptions and no output schema, the description is highly incomplete. It does not explain what inputs are needed, what output to expect, or how the tool fits into a workflow beyond the vague 'before generating SVG'. This is inadequate for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameter names, types, or semantics. It refers to 'copy' and 'layout limits' but does not map to the five parameters (headline, body, cta, mode, template). The agent cannot infer parameter meaning from this description, which is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific multi-step action: correct and report spelling, then check layout fit, then generate SVG. This clearly distinguishes it from validation tools like validate_svg_artifact or creation tools like create_social_svg, though the exact scope of 'SAMPLE layout limits' is somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a temporal usage ('before generating SVG') but does not explicitly mention alternatives or conditions for when not to use this tool. It lacks guidance on when to prefer other tools like validate_design_spec or create_social_svg, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a proposed design against the strict SAMPLE 2026 brand palette, typography, logo, and format rules.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | final | |
| fonts | No | Font families or font descriptors used by the design. | |
| colors | No | Color names or hex values used by the design. | |
| widthPx | No | ||
| heightPx | No | ||
| usesLogo | No | ||
| assetType | No | other | |
| assetBasePath | No | Optional asset directory used to verify officialLogoHref. | |
| officialLogoHref | No | Optional href/path for an approved logo file listed in assets/manifest.json. If omitted, create_social_svg auto-selects a packaged official SVG logo. | |
| hasOfficialLogoAsset | No | Legacy hint only. Final validation requires officialLogoHref. | |
| usesDecorativeElements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so no repetition credit is needed. The description adds the useful context that validation is 'strict' and scoped to the SAMPLE 2026 system, but it does not disclose validation outcomes (pass/fail vs. violation list) or failure behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence where every word earns its place: 'Validate' states the action, 'proposed' frames the lifecycle stage, 'strict' signals enforcement level, and the four rule areas enumerate scope. No filler, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a complex input surface (11 optional parameters, no output schema), the description says nothing about what the validation produces, what minimal input constitutes a meaningful check, or how draft mode alters strictness. An agent cannot predict the result shape or know whether an empty invocation returns a pass, a warning, or an error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 45%, so the description must compensate for the six undocumented parameters. It maps palette/typography/logo/format onto the color/font/logo/dimension parameter groups, but leaves key parameters opaque in both schema and description — notably mode (draft vs. final), assetType, usesLogo, and usesDecorativeElements. The draft/final distinction is especially consequential for a validation tool and is never explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Validate'), a specific resource ('a proposed design'), and the precise standards applied ('strict SAMPLE 2026 brand palette, typography, logo, and format rules'). This is specific enough to distinguish it from siblings like validate_svg_artifact and qa_social_layout, which target structural file validity and layout QA rather than brand-compliance review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the word 'proposed' (pre-production validation) and the enumerated rule areas, but the description never states when to prefer this tool over validate_svg_artifact, qa_social_layout, or create_social_svg, nor does it offer exclusions. There is no explicit when/when-not guidance, only an inferred lifecycle stage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reject browser-only SVG features that commonly trigger missing-link or plug-in warnings in Adobe Illustrator. Requires SVG 1.1, xlink:href base64 raster embedding, editable installed fonts, inline vector logos, and no live SVG filters.
| Name | Required | Description | Default |
|---|---|---|---|
| svg | Yes | Full standalone SVG markup to check for Adobe Illustrator compatibility. | |
| mode | No | final |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful domain context—what the validator checks and requires—but does not disclose what a rejection looks like or what output the tool returns, which matters given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary action is front-loaded, and the second sentence packs the key requirements compactly. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's purpose and input constraints are adequately covered, but return behavior is not described and the mode parameter is left unexplained. Since no output schema exists)Skip; the description should at least say what a rejection result contains. Sibling differentiation is also only implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the svg parameter has a description, but mode only has an enum and default. The description adds meaning to svg by listing concrete compatibility constraints (SVG 1.1, base64 xlink:href, embedded fonts, no live filters), but it says nothing about mode's draft/final distinction or how mode affects validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Reject browser-only SVG features' for Adobe Illustrator compatibility. It clearly distinguishes this tool from generic siblings like validate_svg_artifact by naming the Illustrator-specific risk (missing-link or plug-in warnings) and the exact compatibility requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: use this when validating SVGs for Adobe Illustrator compatibility. However, it does not explicitly state when to prefer this over sibling validation tools, nor does it mention when not to use it. The requirement list gives context but no direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a completed SAMPLE one-pager directly from its local workspace file path. The MCP reads the SVG server-side and returns only a compact validation report, avoiding truncation of large SVG or embedded-image payloads. This includes both strict one-pager and Adobe Illustrator validation.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | final | |
| filePath | Yes | Absolute path or SAMPLE-workspace-relative path to the completed SVG file. | |
| template | No | Expected locked one-pager template id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It does disclose meaningful behavior: the MCP reads the SVG server-side, returns only a compact validation report, and avoids truncation of large SVG or embedded-image payloads. However, it does not describe what the report contains, how failures are surfaced, or whether any state is modified. This is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: the first front-loads the purpose and input mechanism, the second explains why the server-side read matters (truncation avoidance), and the third states the scope of validation. Every sentence earns its place with little redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough for an agent to attempt a call: completed one-pager, local file path, server-side read, and compact report. But without annotations or an output schema, the agent is left guessing about report format and the precise effect of mode and template. Given the crowded sibling-tool space, this is a moderate completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes filePath and template, and the description reinforces filePath as the local workspace path. Mode only has an enum with a default, and the description does not explain the draft/final distinction or how it affects validation. With 67% schema coverage Summary, the description adds modest value but does not compensate for the missing mode semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the verb ('Validate') and resource ('completed SAMPLE one-pager') and adds the key mechanism: reading the SVG server-side from a local workspace file path and returning a compact validation report. It also signals that both strict one-pager and Adobe Illustrator validation are covered. It does not explicitly distinguish this tool from its sibling validators like validate_one_pager_svg, but the file-path/server-side reading detail strongly implies the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when validating a completed one-pager from a local file path)Skip and when avoiding truncation of large SVG or embedded-image payloads is desirable. However, it does not explicitly say when not to use it or name alternatives such as validate_one_pager_svg or validate_illustrator_svg. The usage context is present but mostly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compatibility validator for callers that already hold complete SVG markup. For normal one-pager workflows use validate_one_pager_file so large SVG and embedded-image payloads never pass through chat.
| Name | Required | Description | Default |
|---|---|---|---|
| svg | Yes | Full standalone one-pager SVG markup. | |
| mode | No | final | |
| template | No | Expected locked one-pager template id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the key behavioral context that this tool avoids passing large payloads through chat, which is a meaningful operational constraint beyond the annotations. It doesn't detail validation failure behavior, but the annotations carry the main safety burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary purpose is front-loaded, and the alternative routing is stated in the second sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only validator with no output schema, the description covers the core usage context: what input is expected, when to use it, and why it exists. It doesn't describe the return value or validation criteria, but given the annotations and schema richness, the description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%: the 'svg' and 'template' parameters have descriptions, while 'mode' only has an enum and default. The description adds context about the svg parameter ('Full standalone one-pager SVG markup') and the template parameter ('Expected locked one-pager template id'), but doesn't add meaning beyond the schema for 'mode'. Baseline 3 is appropriate since the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a compatibility validator for callers that already hold complete SVG markup, and explicitly distinguishes it from validate_one_pager_file. The verb 'validate' plus the resource 'one_pager_svg' makes the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('callers that already hold complete SVG markup') and when not to ('For normal one-pager workflows use validate_one_pager_file'), naming the alternative and the reason (avoid passing large SVG and embedded-image payloads through chat). This is clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a generated SVG artifact against SAMPLE brand rules and the Illustrator-safe SVG 1.1 export contract, including approved fonts, palette discipline, social dimensions, embedded raster compatibility, and official logo usage.
| Name | Required | Description | Default |
|---|---|---|---|
| svg | Yes | Full standalone SVG markup to validate. | |
| mode | No | final | |
| assetType | No | social | |
| requiresLogo | No | ||
| assetBasePath | No | Optional asset directory used to verify official logo references. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating validation. The description adds context about what is validated (fonts, palette, dimensions, raster compatibility, logo usage) but doesn't disclose return format, error behavior, or how strict the validation is. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose (validate a generated SVG artifact) and then lists the validation dimensions. It's efficient and every phrase earns its place, though it could be slightly more structured with explicit parameter mapping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with readOnly and idempotent annotations, the description covers the main validation areas. It doesn't explain return values, but there's no output schema and validation tools typically return pass/fail details. The main gap is not explaining the mode parameter (draft vs final) and how it affects validation strictness, which an agent would need to know for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, so the schema documents svg and assetBasePath but not mode, assetType, or requiresLogo. The description mentions social dimensions and official logo usage, which maps to assetType and requiresLogo, but doesn't explain the mode parameter or how assetBasePath is used beyond 'verify official logo references'. The description adds some meaning but doesn't fully compensate for the 60% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a generated SVG artifact against SAMPLE brand rules and the Illustrator-safe SVG 1.1 export contract, listing specific validation dimensions (fonts, palette, dimensions, raster compatibility, logo usage). This distinguishes it from siblings like validate_illustrator_svg and validate_design_spec by naming the SAMPLE brand rules and export contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: after generating an SVG artifact, to check it against brand rules and the Illustrator-safe export contract. It doesn't explicitly name alternatives or exclusions, but the specific validation scope (SAMPLE brand rules, Illustrator-safe SVG 1.1) gives clear context. Sibling names like validate_illustrator_svg and validate_design_spec exist, but the description doesn't explicitly route between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0audit_brand_assetscreate_generation_promptcreate_one_pagercreate_quote_postcreate_social_svgget_brand_guidelinesget_mcp_statusqa_social_layoutvalidate_design_specvalidate_illustrator_svgvalidate_one_pager_filevalidate_one_pager_svgvalidate_svg_artifactScored across 13 tools
Several validators have heavily overlapping purposes: validate_svg_artifact, validate_illustrator_svg, validate_one_pager_file, and validate_one_pager_svg all target Adobe-Illustrator-safe SVG compliance with slightly different entry points. create_quote_post also duplicates functionality already covered by create_social_svg when template=quote, making tool selection genuinely ambiguous.
Tool names mostly follow a clear verb_noun pattern: get_*, create_*, validate_*, audit_*. The main deviation is qa_social_layout, where 'qa' is an acronym used as a verb, but it is still readable and consistent with the overall imperative style.
13 tools is at the upper end of a reasonable scope for a brand-compliance SVG generation server. The count is defensible, though the multiple near-duplicate validators make the set feel slightly heavier than necessary.
The server covers the core workflow well: retrieving guidelines, auditing assets, validating design specs, generating branded SVG outputs, and validating final artifacts. Minor gaps exist, such as no explicit template-listing tool, but agents can complete the main creation and validation flow without dead ends.
Brand-safe MCP for AI agents to create editable, on-brand graphics and automate variants.
Generate marketing images, videos and audios for campaigns, product content, and brand assets.
Generate branded images at scale: design templates and render them to PNGs by prompt.
On-brand ad creative generation: teach it your brand once, generate images and video forever.
