Skip to main content
Glama

get_taste_interview

Read-only

Generates a deterministic calibration interview for a project's design taste, starting with core questions on identity, aesthetic, voice, and matchers. Offers optional deeper questions on design dimensions and voice registers.

Instructions

START HERE on a NEW project: returns a deterministic calibration interview. By default (depth:'first_run') it is COMPRESSED to just 4 core questions — identity, aesthetic, voice, matchers — so a first-time kickoff is fast; every other question (references, the remaining ten design dimensions, any learned dimensions, rule exceptions, and the open-ended special question) is still returned under more_questions for the agent to offer as optional deeper calibration. Pass depth:'full' to get everything at once as a single flat questions list (the eleven design dimensions — typography, spacing, color, layout, motion, imagery, entrance, loading, navigation, aesthetic, libraries — each grounded in what the profile already enforces and most carrying multiple-choice options; the libraries question names specialty tech in plain outcome language and states the default build target for sites: a Next.js app, unless the user prefers otherwise). The voice question always renders the same message in three registers (formal-technical / warm-conversational / punchy-editorial) so the user picks by ear, not by adjective — asked even when the profile has zero voice rules. Every question carries skippable + priority ('core'|'extended'); only identity is required. A 'references' question (offered in more_questions on first_run) invites example URLs/screenshots/files, each interviewed with follow-ups about what specifically draws the person, folded into the matching design_notes. The full interview closes with an open-ended 'special' question (any texture, signature detail, motif, or easter egg nothing else asked about); once the person has other bound surfaces, it carries suggestions — the special touches they chose elsewhere. Ask the user the returned questions conversationally, then persist the answers with bind_taste_surface (dimension answers go in design_notes). Run this BEFORE the first audit_taste on any project that has no binding yet — audit results include a calibration_hint when calibration is missing. When a user dislikes generated/designed output on an ALREADY-calibrated project, re-run with mode:'refine' instead of starting over — dissatisfaction is a calibration signal, not a dead end: it requires an existing binding, then interviews what specifically fell short, offers to keep/tighten/replace each stored design_notes value, re-asks voice, and offers to log a reject precedent via label_finding. mode defaults to 'kickoff'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'kickoff' (default) calibrates a project with no binding yet. 'refine' re-interviews an ALREADY-bound project after the user rejects generated/designed output — requires an existing binding (throws naming get_taste_interview kickoff otherwise) and asks what fell short, then per-dimension keep/tighten/replace, then voice, then an optional reject precedent.
depthNo'first_run' (default) returns only the 4 core questions (identity, aesthetic, voice, matchers) plus a `more_questions` array with everything else for optional deeper calibration. 'full' returns every question flattened into `questions`, as before.
profileYesTaste profile name (see list_taste_profiles).
projectNoProject identifier the binding will be saved under, e.g. 'raven-mcp' or 'portfolio'. Include it so the interview can show any existing binding.
Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds significant behavioral context: it's deterministic, returns questions with skippable/priority, voice question format, refine mode behavior (requires existing binding, per-dimension adjustments), and structure of compressed vs full interview. No contradictions 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.

Conciseness3/5

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

The description is extremely verbose with multiple paragraphs containing extensive detail. While every sentence adds value, it lacks conciseness and could be better organized for quick scanning. Front-loads the main purpose but then goes into exhaustive specifics.

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 thoroughly explains the return structure: questions with properties, more_questions for optional depth, refine mode behavior, and special question with suggestions. It covers all aspects of the tool's behavior and usage for both modes and depths, making it complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description enriches parameter meaning: explains mode defaults to 'kickoff', depth defaults to 'first_run', and details the effects of each enum value (e.g., refine requires existing binding, full flattens questions). It also clarifies that profile is required and project is optional, adding context beyond 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 clearly states the tool returns a deterministic calibration interview for taste profiles, specifying it as the starting point for new projects. It distinguishes between depth modes and explains the resource (taste interview) and action (get), making the purpose unambiguous.

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?

The description provides explicit guidance: 'START HERE on a NEW project', 'Run this BEFORE the first audit_taste on any project that has no binding yet', and when to use mode:'refine' instead of starting over. It also tells what to do with the output (ask questions, persist via bind_taste_surface) and mentions audit includes calibration_hint when missing.

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