How to make AI agents generate on-brand presentations using MCP

Why every AI-generated deck looks the same

You've seen it. You ask Claude or ChatGPT to "create a pitch deck for our product," and thirty seconds later you're staring at a purple-to-blue gradient, Inter or Poppins font, rounded cards with soft shadows, maybe a sprinkle of emoji bullet points. Technically a presentation. Just not your presentation.

So you paste your brand guidelines into the prompt. "Use #1A2B3C as the primary color. Headings in Montserrat, body in Open Sans. Logo top-left, never stretched." The first slide looks decent. By slide four the model has drifted back to its comfort zone, and you're prompting it again to fix the colors and fonts.

The output isn't even bad. It's a well-designed deck for a company that doesn't exist, some imaginary SaaS startup in the training data whose default colors and fonts end up in every deck the model makes. This post is about getting the model to design as your company, and the fix isn't a longer prompt.

The real problem is missing context

When you ask for a deck, the model knows design in general and nothing about your company. Your brand lives in a Figma library, a PDF from an agency, and a handful of hex codes in someone's head. The model can't see any of it, so it fills the gap with its defaults.

The guidelines you paste are a one-time, lossy copy of your brand. The further the model gets from your original message, the more its training pulls it back toward generic, that's the drift by slide four. And everyone on your team pastes their own version, so everyone's decks come out a little different.

The fix is to let the model look the brand up instead of carrying a copy around in the conversation, a live source it can query for colors, fonts, and layout rules the way it queries a database. Anthropic built MCP for this kind of problem.

Your brand as an MCP tool

Agents do this kind of lookup all the time. Claude Code reads files and runs shell commands mid-task without you pasting their contents into the chat. MCP (Model Context Protocol) is the open standard that extends that to anything you can put behind a server. The server exposes a few named tools, the agent discovers them and decides when to call them. Claude Code, Claude Desktop, and Cursor all speak it.

For our problem, that means your brand becomes an API the agent calls. When it needs your primary color on slide six, it fetches the value fresh with a tool call, no reaching back through the conversation and hoping. The model holds nothing in memory, so there's nothing to drift from.

The response is JSON with exact hex values and font names, ground truth rather than prose to interpret. And the server is one shared source, so updating the brand there updates it for the whole team, in every chat.

That's exactly what SlideSpeak OnBrand does, an MCP server that serves your brand guidelines to any agent. It's also open source on GitHub, so you can read exactly what each tool returns before you connect it.

Setting it up

1. Go to onbrand.slidespeak.co, log in, and link your SlideSpeak account.
2. Add your website. OnBrand reads it and pulls your brand guidelines straight from the site, the colors, fonts, and logo, so you're not assembling anything by hand.

1. Connect OnBrand as an MCP server in your agent. Claude Code, Codex, Cursor, and OpenClaw all speak MCP, each has its own way of registering servers. For Claude Code it's one command.

   claude mcp add --transport http onbrand https://onbrand.slidespeak.co/mcp

1. Use your brand settings to generate assets like presentations.
2. Open a draft that already uses your brand.

Setup takes a few minutes, and you do it once.

What SlideSpeak OnBrand exposes: the tools

Once connected, the server hands your agent a small set of tools. Four do the heavy lifting.

• list_brands returns the brands on your account. If you manage more than one, an agency with client brands or a company with sub-brands, the agent can pick the right one instead of assuming.
• get_brand_guide returns the full guide for a brand as structured data, colors with exact hex values, fonts and where each is used, logo files and usage rules. This is the ground truth the agent pulls from while it designs.
• get_brand_skill is the interesting one. It returns instructions for designing with the brand, not just the raw values. Think of it as a system prompt for your visual identity that the agent loads before it lays out a single slide.
• write_brand goes the other way. Spot a wrong hex value mid-session, or want to add a secondary palette, tell the agent and it updates the brand on the server. The fix lands in the shared source, so the next deck anyone on the team generates picks it up.

The rest of the toolset handles the mechanics, generating a presentation from the brand, downloading the finished file, checking on a long-running job, and uploading a document to build from. You never call them yourself, the agent reaches for them when the task needs them.

The same deck, with and without OnBrand

I reran the exact request from the top of this post. Same prompt, same outline, same content. The only change is that this time the agent has OnBrand connected.

The difference shows up before the first slide renders. In Claude Code you can watch the tool calls come in, the agent lists the brands, loads the brand skill and guide, and only then starts generating with the real hex values and fonts in hand.

Same content on every slide. The colors match the site, the headings use the right font, and the logo sits where the guidelines say it should. Nothing about the prompt got smarter, the agent just stopped guessing.

Beyond decks: where else devs can point this

The pattern isn't tied to slides. Once your agent can query the brand, anything it generates can come out branded. A few places it earns its keep.

• Docs sites. Ask the agent to theme your Docusaurus or Starlight site and it pulls the real palette and type instead of eyeballing the logo. Your theme config ends up with the same hex values as your marketing site.
• README and repo assets. Social preview images, badges, and the hero banner at the top of the README can all use the actual brand instead of whatever the agent felt like that day.
• HTML emails. The most brand-sensitive artifact devs get handed and the most tedious to style. With the guide a tool call away, the agent gets the colors and fonts right on the first pass.
• Internal tools. Admin panels and dashboards are the last thing anyone styles. If the agent scaffolds them with brand context, they match the rest of your product for free.

Things to keep in mind

• The extracted brand is only as good as your website. If your site runs on a stripped-down palette or a fallback font, that's what OnBrand learns. Check the overview page after the first import and correct anything that's off, either in the UI or by telling the agent to write_brand the fix.
• The agent decides when to call the tools. Most of the time it reaches for the brand on its own, but on a long session it can charge ahead without looking. A short nudge like "use the brand" gets it back on track.
• The brand guide covers identity, not taste. Colors, fonts, and logos come out right, but slide judgment is still the model's. A cluttered slide in your brand colors is still a cluttered slide.
• Generation is a background job, not instant. A full deck takes a couple of minutes, so kick it off and keep working while it renders.

Common questions

Does this work with PowerPoint and Google Slides?

OnBrand supplies the brand. The agent decides where the slides land. The colors, fonts, and logos come from the same source whether the deck ends up in PowerPoint, Google Slides, or a web format, so you're not re-styling per tool.

What about content that isn't a presentation?

The same brand library covers one-pagers, proposals, and marketing assets. The agent reads the same colors, type, and logos no matter what it's building, so a one-pager comes out as on brand as a deck.

Try it yourself

Set up your brand at onbrand.slidespeak.co, connect the MCP server to your agent, and ask for a deck the way you always do. The first on-brand draft takes a few minutes, most of it spent on the one-time setup. The source is on GitHub, and you can learn more about OnBrand on the feature page.

If you try it, I'd like to hear how it goes. Drop a comment with what you built, what broke, or the question you wish this post had answered.