Skip to main content
Glama

generate_mood_board

Destructive

Create a mood board from the project's design notes, captured references, and your own images, saving an HTML file with a PNG preview—an approval step before the design-system generation.

Instructions

Compose a mood board from what the Taste Engine already holds for a bound project — the binding's design_notes as chips, its captured references, and pattern-library thumbnails captured from those same reference sites — written as one self-contained HTML file (plus a best-effort PNG of the board) under the taste home's moodboards/ directory, or output_dir. Pass image_paths to embed the user's OWN images too — a generated brand pack, product shots, mood images — shown as a 'Your assets' section (they are the user's material, so no third-party credit rides on them). Use it right after the kickoff interview binds a surface ('get a mood board going'), or pass mode:'example' to show a labeled sample board to a user who has never made one, to get their thinking started BEFORE the interview. The board invents nothing: note text stays text (never fabricated color swatches), the ground (light/dark) is measured from the captured references' scheme traits, and every embedded pattern carries its credit. It is an APPROVAL STOP: the result and the board's footer name generate_design_system — the taste engine's core output — as the next step once the user says the direction is right; this tool never runs it. mode:'board' requires an existing surface binding and throws naming get_taste_interview when there is none.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'board' (default): compose the real board from the project's binding. 'example': write a clearly-labeled sample board that shows what a mood board is — use it to seed the user's thinking before calibration.
profileYesTaste profile name (see list_taste_profiles).
projectNoBound project name (see get_taste_interview / bind_taste_surface). Required for mode:'board'; ignored for mode:'example'.
output_dirNoDirectory for the board files. Defaults to <taste home>/moodboards.
image_pathsNoLocal file paths to the user's OWN images — a generated brand pack, product shots, mood images — embedded into the board as a 'Your assets' section (png/jpeg/gif/webp, sniffed from the bytes; unusable paths are skipped with a named warning, never silently). Use absolute paths: a relative path resolves against the server process's cwd (usually not your project), and ~ is not expanded. mode:'board' only; ignored with a warning for mode:'example'.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv2.5.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses key behavioral traits: the board never invents swatches, ground scheme is measured, pattern credits are preserved, unusable image paths are skipped with a named warning, and mode:'board' throws when no surface binding exists. It also flags the tool as an APPROVAL STOP and explains the downstream design-system generation it does not invoke.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense but long and run-on, mixing many clauses in a single paragraph. Every sentence contributes value, but the structure could be broken into shorter, more scannable statements. There is no filler, yet it does not achieve the concise front-loaded clarity of the best definitions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description fully compensates by specifying the output files (HTML + best-effort PNG), the output location, the two modes, prerequisites, error behavior, and next steps. It also covers important edge cases such as image-path handling and missing surface bindings, making the description a complete guide for calling the tool.

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%, so the baseline is 3. The tool description adds a little framing for image_paths and mode:'example', but those are mostly already present in the parameter descriptions. The description does not meaningfully compensate or enrich parameter semantics beyond the schema.

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?

The description opens with a specific verb and resource — 'Compose a mood board' — and enumerates precisely what goes into it (design_notes chips, captured references, pattern-library thumbnails) and where it is written (moodboards/ directory or output_dir). It also differentiates this tool from the closely related generate_design_system by explicitly stating this tool never runs it, and it disambiguates the two modes ('board' and 'example').

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?

Provides explicit when-to-use guidance: right after the kickoff interview binds a surface, or with mode:'example' to seed thinking before the interview. It also names alternative/fallback tools — get_taste_interview for missing binding and generate_design_system as the next step — and states when this tool is never to be used (it never runs the system).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rhinocap/raven-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server