Building an MCP Server That Serves Brand Guidelines

Building an MCP server that serves brand guidelines is a content-architecture project before it is an integration project. Brand identity must become structured, machine-readable context, with resources agents can read and tools they can invoke. MCP supplies the shared channel, but explicit, versioned brand rules make that channel authoritative.

What MCP is and why brand guidelines need it

Brand guidance in PDFs, slide decks, and portals gives agents no dependable shared reference. An agent writing copy may parse one document, while an agent building a page works from an extract of another. Neither has a reliable update path when the brand changes. Without a standard way to request authoritative rules, agents improvise from whatever context reaches them.

Model Context Protocol is an open standard through which AI applications discover external data and invoke external functions. It replaces separate client-to-system connectors with a server that any compatible client can use. Claude, ChatGPT, Cursor, Claude Code, Codex, and VS Code support MCP natively. The integration therefore need not be rewritten for each client. Anthropic open-sourced MCP on November 25, 2024, and it is now a project of the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI.

The three MCP primitives and how they map onto brand work

MCP exposes three kinds of capability, which are resources, tools, and prompts. Resources are read-only data supplied as context, and the host application decides when to load them. A brand resource might make the approved design token catalog available before an agent starts a page. This makes context loading an application responsibility. The resource provides the reference against which subsequent work can be judged.

Tools are functions the model selects and invokes with parameters. A brand tool might retrieve the correct logo variant for print or check an asset against approved specifications. Unlike a resource, it performs an operation. The specification calls for explicit user consent before tool invocation, while acknowledging that MCP cannot enforce that principle at the protocol level. Hosts must therefore check that the user has given consent.

Prompts are predefined instruction templates triggered by the user. A LinkedIn post template might preload the channel’s tone rules and messaging constraints. Treating all three as prompt text discards those separate controls.

Why brand guidelines in their current form cannot serve as MCP resources

Guidelines for people use prose, screenshots, and examples to explain what the brand intends. That is appropriate for designers interpreting a visual system, but insufficient for machine-readable enforcement. Uploading the same PDF to a server changes its location while preserving its structure. An agent may read “use warm, approachable language” without gaining a criterion it can test. Readable text is not the same as evaluable context.

Conditional rules make the intended behavior more explicit. A rule such as “if channel=LinkedIn, tone=professional; if channel=Instagram, tone=conversational” gives the agent a channel-specific instruction. Concrete constraints then give the agent checks it can run, which broad tone labels cannot do. Likewise, a content schema defines required fields, while explicit metadata makes assets discoverable without prior knowledge of naming conventions.

Design tokens provide the clearest example of this conversion. A color hex value with a defined role can be used directly, whereas “use our signature blue” depends on interpretation. The W3C Design Tokens Community Group specifies JSON for design token exchange. Style Dictionary can generate CSS, Tailwind config, and other outputs from that source.

How to structure brand identity so an MCP server can serve it

The practical architecture is a library of dedicated context files organized by brand dimension. Each file contains explicit rules for a bounded part of the identity, allowing the server to select relevant context. JSON is the safest base format for structured constraints and tokens. Markdown can serve prose-heavy voice and messaging rules when consistent headings and list formats enforce its structure. Free-form documents do not provide the same dependable boundaries.

The voice and tone file should spell out which words are banned, which sentence patterns are required, and which punctuation rules and channel-specific conditions apply. The messaging file should link positioning pillars to the approved claims that support them and the framings that are banned. These are separate checks on the same output. Copy can follow the right sentence pattern while making an unapproved claim, so neither file substitutes for the other. Their separation lets a brief select both without loading unrelated visual rules.

The visual identity file should contain JSON design tokens with color hex values and semantic roles, including primary, secondary, error, and success. It should also set out type sizes and weights, spacing units, and numeric ratios for logo clear-space. An imagery file addresses a different selection problem. It should express photography style, illustration approach, and excluded image types as criteria that an agent can apply when choosing or reviewing assets.

Audience and ICP files should define personas and approved or banned language by buyer stage and channel. Offering scope should state what the brand does and does not do, limiting unsupported product claims. Agencies should keep these files in version-controlled collections, with one for each client brand. Each client schema should cover design tokens, channel architecture, editorial rules, and compliance constraints, such as claims that are forbidden and regulatory citations that apply. The brand identifier then determines which rules the server loads.

Resources, tools, and the credential boundary: building the server correctly

Community filesystem, database, and GitHub servers handle horizontal operations, while the custom brand server decides which tokens, channel rules, and asset variants apply. Reading a file is not evaluating its contents. A filesystem server can get design token JSON, but a brand tool should check a proposed color combination against the brand contrast rules.

When several servers are connected, the orchestrator discovers them, applies policy, and presents prefixed tools to prevent naming collisions. It routes model calls into JSON-RPC invocations over the appropriate transport. Transport follows the deployment model. Stdio suits local subprocess servers, Streamable HTTP suits a centrally hosted brand authority, and an in-process SDK suits tools tightly coupled to a product. Under the July 28, 2026 specification, each request carries its own protocol-version and client-capability information in the _meta field, which replaces the earlier initialization handshake.

Credentials stay out of the model’s context at every step of this process. The model supplies an operation name and parameters, while the server executes with credentials provided through environment variables at startup or Authorization headers in the server descriptor. The June 2025 specification update classified MCP servers as OAuth Resource Servers and introduced protected resource metadata. That metadata identifies the appropriate Authorization Server. Resource indicators show which resource should receive the token and help protect it from being redirected to another resource.

Production safeguards must cover behavior as well as access. A review tool should change brand files only after a confirmation gate, and contract tests should catch tool-signature drift that stops context from reaching the client. Client isolation is equally important for agencies. When servers that should be separate share memory, one client’s brand context can leak into another session. Retry loops need circuit breakers so an unavailable brand server produces a graceful failure and a missing-context warning.

What a brand tool looks like in practice: the brief, the check, and the update

A brief tool takes a task description and channel, with a brand identifier for multi-brand deployments. It loads the relevant client schema and returns a structured brief containing the applicable logo variant, type rules, color tokens, imagery constraints, and voice rules. The return is a task-scoped subset of the brand. This keeps guidance that the creative task does not need out of its context and saves the operator from choosing client documents by hand.

A review tool takes a finished asset or content piece and evaluates it against the resource files. Its report returns a pass or fail for each criterion, evidence for the check, and the rule or token the output should have followed. A useful finding shows that background color #F2E8D0 does not match approved warm-neutral token #FAF6F0 and points to brand/colors.json line 14. Running that check before release lets the team fix errors as part of the workflow.

An update operation changes the brand resource files and versions the resulting context. Its input concerns the changed rules, such as a revised palette, logo, or tone policy, and its output is the updated, versioned resource set. Connected agents receive the new version on their next request. Unlike a pasted prompt, the change does not require manual re-briefing across every workflow and template. Versioning also provides a record of the rules in force for an asset, with rollback capability and a basis for staged rollouts.

Webflow’s MCP server works within existing roles and permissions, with site-level Agent Instructions covering brand, design system, asset, and CMS guidelines. The rules reside in configuration. zeroheight’s hosted remote MCP server lets agents list pages, read content, and pull assets with release targeting and permission scoping. Its design-system access therefore has both a release boundary and an access boundary.

Pinterest’s enterprise MCP architecture, published March 19, 2026, uses domain-specific servers, a central discovery registry, and human approval for high-risk operations. Servers must pass Security, Legal/Privacy, and, where applicable, GenAI compliance reviews before production deployment. Adobe GenStudio uses brand guidelines locked into Adobe Express templates to control what it generates. Creative variants are made within boundaries approved in advance, so checks after production carry only part of the load.

Why a single authoritative brand server matters more as agent count grows

Without a shared source, every additional agent or workflow creates another place where guidance may be pasted, hardcoded, or omitted. When the brand changes, the team must then find copies that may no longer agree. A shared server removes that duplication at the source. Its value grows as more tools and teams depend on the same rules, because updates no longer require separate edits to each agent’s guidance.

A brand identifier in the tool call selects the correct client schema without requiring the operator to load a different context manually. The server becomes the common enforcement point. This shifts governance toward controlling the data and rules used during production, rather than relying only on an approval queue for finished work. Shared context gives every review and generation operation an authoritative reference.

Making the brand layer genuinely agent-ready: what has to be true before you build

An MCP server can enforce only what the brand has defined precisely enough to evaluate. Before implementation, the identity therefore needs JSON design tokens, explicit voice constraints, approved claims paired with banned framings, and usable imagery criteria. It also needs one canonical dataset. A brand guide in Notion, tokens in Figma, and a voice document in Google Drive do not form an authoritative source merely because they are nominally consistent.

The update process must be settled before deployment. A team needs a defined versioning process, an update frequency, and rollback policy so the served context remains aligned with the brand. Exposure requires equally explicit decisions. The scope must cover available resources, tools, and prompts, together with an open or user-authenticated access model. Read access and permission to change brand rules should not be treated as the same decision.

The team must decide error handling and fallback behavior when the server is unavailable, integration with existing brand infrastructure, and analytics for understanding how agents use brand context. MCP supplies a standard distribution mechanism, but the quality of brand enforcement still depends on the definitions, permissions, and update discipline behind it.