Skip to main content
Glama

Dali by Lulu


Score your creative against what's actually winning in the ad market — before you spend the credit.

Most AI generation failures are predictable. A weak prompt, an off-formula creative — you can't tell until after you've burned the token. Dali scores it first, and it doesn't grade against opinions or generic "prompt tips." It grades against a real, living corpus of proven-winning ads — creatives still running in the market months after launch, scraped, embedded, and ranked. Two jobs:

  • score_prompt — judge the prompt before you generate (craft: camera, motion, lighting, model-native language).

  • score_creative — judge the actual image against proven winners (does it look like what converts, and what's missing).

Every wasted generation has a real cost — a Seedance retry is ~$6. The live dashboard tracks what the community has saved by catching bad creatives before they burned a credit.

You: "make a video ad for our glass serum bottle"

dali::score_prompt(prompt, "veo3")
→ 8/100  Grade: F
→ no camera move · no motion · no lighting · 8 words
→ Verdict: Generic stock footage guaranteed. Enhance first.
→ enhancement_brief included (score < 70):

  ① lead with camera — Veo 3's #1 lever: "Slow dolly", "Orbital push"
  ② describe physics: "a drop falls", "liquid ripples", "glass refracts"
  ③ lighting type + quality: "warm backlight", "rim-lit edges"
  ↳ [Camera]. [Subject + motion]. [Lighting]. [Mood]. [No text.]

✦ YOUR LLM rewrites using the brief:

  "Slow orbital push around a glass serum bottle on white marble. A single
   amber drop falls in extreme slow motion, catching warm backlight. Macro:
   liquid gold ripples outward from impact. Rim-lit edges, soft studio
   diffusion. Premium, clinical. No text."

dali::score_prompt(enhanced, "veo3")
→ 91/100  Grade: A  ✓ Safe to generate.

The real winning data layer

This is what makes Dali more than a prompt linter. The scores are grounded in real ads that are actually winning, not hand-written rules.

How the corpus is built — longevity is the outcome signal. We scrape the public Meta Ad Library. An ad still running months after it launched is one the advertiser keeps paying for — a proven winner. That "still-running-after-N-days" longevity is a market-validated label you can't fake, and it's the spine of the whole dataset.

What's in it, today:

Ads ingested

10,204 (14,100 raw archive)

Proven winners (long-running)

3,808

Distinct advertisers

4,121

Verticals

8 — beauty, wellness, supplements, fitness, food, apparel, tech, pets

Winner creatives embedded

800 (1408-dim, balanced ~100/vertical)

Longest-running winner seen

2,431 days (6.6 years live)

The pipeline (offline → serving). The tools never scrape or embed on the fly — they read pre-built stores:

scrape Meta Ad Library         → proven winners (longevity label)
      → Gemini vision           → creative attributes (lighting, format, before/after, offer…)
      → prevalence SQL          → winning-pattern lift per vertical (winners vs baseline)
      → Vertex embeddings       → BigQuery VECTOR_SEARCH (nearest proven winners, cosine)
      → graph edges (Memgraph)  → (:Pattern)-[:WINS_IN {lift, n}]->(:Category)

So when score_creative runs, it embeds your image and finds the actual winning ads it most resembles by full visual signature — then tells you which winning attributes you're missing. When enhance_prompt runs with a category, the rewrite brief is backed by real market lift ("before/after shows up in 78% of winning wellness ads, 4× baseline"), not craft opinion.

Honest scope. The winner label is longevity (a strong market-validated proxy), not per-ad conversion rate — measured CVR validation is in progress. The corpus grows on a schedule, so coverage per vertical keeps deepening. What you get today: your creative scored against what's demonstrably surviving in the live market.

dali::score_creative(image_url, "beauty")
→ score 62/100  — partial resemblance to proven winners
→ looks_like:      Frøya Organics (ran 411d), tashportcosmetics (884d), Face Reality (346d)
→ what_to_change:  winners use "before/after" 4× more · offer-visible 1.8× more
→ defects:         none
→ Verdict: Partial — strong resemblance, but add the high-lift attributes before spending.

Related MCP server: Prompt Auto-Optimizer MCP

Contents


Install

Hosted MCP — connect once, scores every prompt and creative:

# Claude Code
claude mcp add --transport http dali https://dali.getlulu.dev/mcp
// Cursor / Windsurf — .cursor/mcp.json or windsurf settings
{
  "mcpServers": {
    "dali": { "url": "https://dali.getlulu.dev/mcp" }
  }
}
// stdio-only clients — npx wrapper around the hosted server, no Python needed
{
  "mcpServers": {
    "dali": { "command": "npx", "args": ["-y", "dali-mcp"] }
  }
}

Full install guide with all clients

Self-hosted — local, no auth required:

pip install dali-mcp
claude mcp add dali -- python -m dali.server

The self-hosted package exposes the prompt-scoring tools locally. The creative-scoring tools (score_creative, analyze_winning_formula) and the winning-ad corpus run on the hosted server — connect via the hosted MCP to use them.


Tools

Score the creative — against real winners

Tool

What it does

score_creative(image_url, category)

Score an actual ad image. Embedding similarity to proven winners is the headline score; also returns the winners it resembles, which winning attributes it's missing, and generation defects — in one call

score_creative_from_view(category, …)

Score an image you're looking at (pasted/attached in the chat) — no URL. The model reads the creative's attributes and Dali scores them against the winning corpus (verdict + what to change). Use for images shared in-conversation; score_creative (URL) adds the embedding headline

analyze_winning_formula(csv, category, email)

Paste your own ads export (creative URL + CPA/CTR/ROAS) → your winning formula vs your losers, plus how you compare to the industry median

Score the prompt — before you generate

Tool

What it does

score_prompt(prompt, model, category?)

Grade 0–100 with a per-dimension breakdown and verdict. When the score is weak, the rewrite brief is returned in the same call. Reads intent with the conversation LLM (understands negation, any language)

enhance_prompt(prompt, model, category?)

Returns a structured rewrite brief — YOUR LLM writes the enhanced prompt. With a category, the brief is backed by real winning-ad lift

track_enhancement(original, enhanced, generator)

Record a before/after pair in the graph brain — trains community patterns

score_variations(prompts, generator)

Rank a list of prompt variants in one call — highest to lowest

suggest_generator(concept, budget_usd_max)

Pick the best model for your concept + budget

The graph brain & meta

Tool

What it does

creative_patterns(model)

Community top patterns for this model from the graph

community_benchmark(prompt, model)

Compare your prompt against community top scorers

prompt_neighbors(prompt, model)

Find A/B-grade prompts that share your patterns (score the prompt first, so its patterns are in the graph)

analyze_intent(prompt)

Parse dimensions: camera, motion, lighting, style, mood, gaps

my_story()

Your scoring history, model stats, grade distribution

list_generators()

All supported models with medium and core strength

dali_version()

Server version + changelog


Supported models

Video

Model

Platforms

Best for

Prompt style

veo3

Higgsfield, Google AI Studio (veo-3.1-generate-preview), Runway

Cinematic brand films, narrative ads, photorealistic motion

Camera move → Subject → Action → Location → Lighting → Mood

seedance

Higgsfield, fal.ai (bytedance/seedance-2.0)

UGC, social-native content, TikTok/Reels performance ads

Natural language, motion-first, authentic feel

kling

Higgsfield (kling3), Kling.ai (kling-v3-text-to-video)

Character animation, product showcases, facial performance

Scene → Characters → Action → Camera → Style; multi-shot labels

runway

Runway (gen4_turbo)

VFX, character performance, cinematic motion

Motion-first — describe what moves, not what exists

wan

fal.ai (fal-ai/wan/v2.7/text-to-video)

4K, 20-second clips, native audio, open-source workflows

Scene → Motion → Sound → Duration → Mood

minimax

fal.ai (fal-ai/minimax/hailuo-02/pro/text-to-video)

Cinematic storytelling, character animation

Natural language + [camera movement] bracket syntax

higgsfield

Higgsfield (native model)

Physics-driven motion — cloth, hair, fluid, particles

Describe materials in motion, not motion abstractly

Sora 2 (OpenAI): API shutdown September 24, 2026. Do not build new dependencies on it — use Runway or Kling instead.

Image

Model

Platforms

Best for

Prompt style

flux

BFL API (flux-pro-v1.1), fal.ai, Replicate

Photorealism, technical photography, product shots

30–80 words; camera body + lens specs; front-load subject

midjourney

Midjourney (v8.1)

Artistic depth, editorial, stylized illustration

Prose + params appended: --ar 16:9 --s 300 --v 8.1 --style raw

ideogram

Ideogram API (V_4), fal.ai

Typography, logos, text-in-image, graphic design

Describe text exactly in quotes inside the prompt

firefly

Adobe Firefly 5 (enterprise)

IP-indemnified commercial assets, 4MP brand content

Natural language + contentClass and style.presets API params

Imagen 4 (Google): deprecated — use gemini-3.5-flash with image output. Dali still scores legacy Imagen prompts via the imagen model key but don't build new things on it.


Platform supersets

Higgsfield and Runway are aggregator platforms — they proxy multiple underlying models under one API. The model you pick matters more than the platform name:

Platform

Model selector

Underlying model

Higgsfield

veo3

Google Veo 3.1

Higgsfield

seedance

ByteDance Seedance 2.0

Higgsfield

kling3

Kling 3

Higgsfield

wan2-7

Wan 2.7

Higgsfield

image2video

Higgsfield native

Runway

veo3

Google Veo 3.1

Runway

gen4_turbo

Runway Gen 4.5

Runway

seedance

ByteDance Seedance 2.0

Dali scores for the underlying model's native prompt language, not the platform wrapper. Pass the model name (veo3, kling, seedance…), not the platform name.


Why model-specific?

Generic prompt optimizers don't know that:

  • Veo 3.1 needs camera movement specified above everything else

  • Kling 3 supports multi-shot scene labels natively in the prompt

  • Flux responds to camera body and lens names like a photographer ("Sony A7 IV, 85mm f/1.4")

  • Midjourney V8.1 reads prose + parameters, not keyword lists

  • Higgsfield simulates physics — you describe materials in motion, not motion abstractly

  • Minimax uses [Pan left] bracket syntax for camera moves — plain text camera commands are ignored

  • Ideogram V4 needs text quoted exactly in the prompt for typography accuracy

  • Wan 2.7 generates native audio — include sound descriptions alongside visuals

Dali has a separate scoring rubric and rewrite brief for each model. Your LLM does the creative rewriting — Dali provides the intelligence.


MCP resources

creative://guide/veo3       → Veo 3.1 camera language guide
creative://guide/seedance   → Seedance UGC motion guide
creative://guide/kling      → Kling multi-shot + expression guide
creative://guide/runway     → Runway motion-first guide
creative://guide/wan        → Wan 2.7 audio + motion guide
creative://guide/minimax    → Minimax bracket camera guide
creative://guide/higgsfield → Higgsfield physics-motion guide
creative://guide/sora       → Sora 2 guide (API shutdown Sep 24, 2026)
creative://guide/flux       → Flux photography brief guide
creative://guide/midjourney → Midjourney V8.1 + parameters guide
creative://guide/ideogram   → Ideogram V4 typography guide
creative://guide/firefly    → Firefly 5 commercial content guide
creative://guide/imagen     → Imagen 4 guide (deprecated Aug 17, 2026)
creative://models           → All models overview

Contributing

Model guides live in dali/data/guides/{model}.json on the hosted server. Found practitioner patterns that consistently produce high-grade results? Open an issue with the model, the pattern, and a sample prompt + result. The best contributions come from Reddit, Discord, and YouTube — real practitioners, not official docs.

Prompt best practices by model — cheat sheets, do/don't tables, top patterns per model → Dali creative flow skill — install this skill so your LLM follows the score → enhance → generate workflow automatically


MIT License · Built by Lulu · dali.getlulu.dev

Available Tools

12 tools
analyze_intentBInspect

Parse a creative prompt into structured intent dimensions.

Returns: detected camera language, motion, lighting, style, mood signals, identified gaps, and which models suit the current signals best.

ParametersJSON Schema
NameRequiredDescriptionDefault
mediumNo"image", "video", or "auto" (default, auto-detected)auto
promptYesRaw creative text (rough idea or full prompt — both work)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only lists return values and does not mention side effects, permissions, rate limits, or destructive potential. This lack of guidance reduces transparency.

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

Conciseness5/5

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

The description is two sentences: the first states the purpose, the second lists the returns. It is front-loaded, concise, and contains no superfluous words.

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

Completeness4/5

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

The description provides purpose and return components, and an output schema exists to detail the return structure. It is mostly complete, though it could briefly differentiate from siblings or note prerequisites.

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 schema already explains both parameters. The tool description does not add new parameter-level details beyond the schema, resulting in a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Parse' and resource 'creative prompt into structured intent dimensions'. The return list provides a specific outcome. However, it does not explicitly differentiate from sibling tools like 'score_prompt' or 'enhance_prompt', so score 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a user wants to analyze a creative prompt's intent, but it does not provide explicit when-to-use, when-not-to-use, or alternative tools. This makes it adequate but not strong.

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

community_benchmarkAInspect

Compare your prompt against community top scorers for this model.

Scores your prompt, then queries the Dali graph to find:

  • Which A-grade community patterns are absent from your prompt

  • Which enhancement patterns would give you the biggest score gain

  • Where you sit vs the community average for this model

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesTarget generation model
promptYesYour prompt to benchmark

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It mentions scoring and graph querying but lacks disclosure on side effects, return format details, or authorization needs.

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

Conciseness5/5

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

Two efficient sentences with a bullet list. Front-loaded with purpose, no wasted words.

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

Completeness4/5

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

Given output schema exists and schema coverage is high, the description adequately explains tool functionality. It could mention expected output shape but that is covered by output schema.

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?

Both parameters are described in the schema with 100% coverage. The description adds context but does not provide semantic details beyond what the schema already includes on individual parameters.

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 compares a prompt against community top scorers for a specific model, listing specific outputs. It distinguishes itself from siblings like score_prompt by focusing on community benchmarking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when you want to see how your prompt compares to community patterns, but does not explicitly state when to use or not use this tool versus alternatives like score_prompt or score_and_enhance.

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

creative_patternsAInspect

Community graph intelligence: which patterns consistently produce high-grade prompts for this model?

Powered by the Dali V3 graph brain — every prompt scored by every Dali user contributes to this. The more community usage, the richer the signal.

Also returns: enhancement unlocks (which patterns added during enhance_prompt have produced the highest score gains for this model).

ParametersJSON Schema
NameRequiredDescriptionDefault
gradeNoMinimum grade filter — "A" (only A-grade), "B" (A+B), "C" (A+B+C)A
modelYesTarget generation model (veo3, seedance, kling, runway, wan, minimax, higgsfield, flux, midjourney, ideogram, firefly)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It discloses community-driven, cumulative data but lacks details on freshness, authentication needs, or rate limits. It mentions 'every prompt scored contributes' but does not explain update frequency.

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

Conciseness4/5

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

The description is three sentences, first front-loads the main purpose. It is reasonably concise, though the third sentence ('Also returns...') slightly disrupts flow. No unnecessary verbiage.

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

Completeness4/5

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

Given an output schema exists, the description sufficiently explains what the tool returns (patterns and enhancement unlocks) and the community signal context. It covers the main purpose without needing to detail output format.

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 coverage is 100%, and the description does not add meaning beyond the schema's parameter definitions. The description mentions 'grade' and 'model' but without elaboration, meeting the baseline.

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 community intelligence on patterns that produce high-grade prompts for a given model, including enhancement unlocks. It distinguishes itself from sibling tools like 'enhance_prompt' (which actually enhances) and 'score_prompt' (which scores single prompts).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for discovering effective patterns, but lacks explicit guidance on when to use this tool versus alternatives like 'community_benchmark' or 'score_and_enhance'. No when-not or comparison is provided.

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

dali_versionAInspect

Return the current Dali server version and changelog.

Useful for checking if your MCP is connected to the latest server, or for debugging version mismatches between the pip package and hosted API.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations given, so description carries full burden. It discloses return value (version+changelog) and implies read-only behavior. No contradictions.

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

Conciseness5/5

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

Two sentences, front-loaded with action. Every word earns its place.

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?

Fully complete for a zero-parameter tool with output schema. No missing behavioral or contextual details.

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

Parameters4/5

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

No parameters, baseline 4. No need to add param info beyond empty 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?

Clear verb+resource: 'Return the current Dali server version and changelog'. Distinct from siblings like analyze_intent or list_models.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: checking server connection and debugging version mismatches. Lacks explicit when-not-to-use but context is clear.

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

enhance_promptAInspect

Rewrite a prompt using AI to score higher on the target model.

Returns a rewrite brief — YOU (the LLM) write the enhanced prompt from it.

Dali provides creative intelligence: what's missing, the model's native language rules, structure template, priority fixes, and length target. You provide creative execution: actually writing the better prompt.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesTarget generation model (veo3, seedance, kling, runway, wan, minimax, higgsfield, sora, flux, midjourney, ideogram, firefly, imagen)
promptYesThe prompt to enhance

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It transparently explains that the tool returns a rewrite brief and that the agent must perform the actual rewriting. It details the content of the brief. It does not mention any destructive behavior or side effects, which are not applicable here.

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

Conciseness4/5

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

The description is efficiently structured with a front-loaded action statement followed by key details about the output and agent's role. It is not overly long, though the second paragraph could be slightly more concise.

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 the tool's simplicity (2 params) and presence of an output schema, the description is complete. It explains the output format (rewrite brief with elements like missing, rules, template, fixes, length target) and the agent's responsibility, leaving no significant gaps.

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 coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions 'target model' and 'prompt to enhance', but the schema already provides descriptions for both parameters. No additional semantics.

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's purpose: to rewrite a prompt for higher scoring on a target model. It uses specific verbs ('rewrite', 'enhance') and resources ('prompt', 'target model'), and implicitly distinguishes from siblings like 'score_prompt' which only scores.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance on how to use the tool's output: the agent receives a rewrite brief and must write the enhanced prompt themselves. It explains the division of labor between Dali and the LLM. However, it does not explicitly state when to use this tool versus alternatives like 'score_and_enhance'.

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

list_modelsAInspect

List all supported generation models with medium, creator, and core strength.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

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

No annotations present, so description carries the burden. It discloses the return type (list of models with attributes) but omits details like read-only nature, authentication needs, or performance characteristics. Adequate for a straightforward list.

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

Conciseness5/5

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

Single sentence, front-loaded with action and resource, no wasted words.

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

Completeness4/5

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

Given zero parameters and presence of an output schema (context indicates it exists), description adequately explains the tool's purpose and output content. Slight deduction for not explicitly stating output schema exists, but not required.

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

Parameters4/5

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

No parameters exist (0 params, 100% coverage). Description adds value by specifying the content of the list (medium, creator, core strength), exceeding the baseline of 3.

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?

Description clearly states the tool lists all supported generation models with specific attributes (medium, creator, core strength). It distinguishes from sibling tools which have different functions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives guidance. However, the simplicity and uniqueness of the tool make overuse unlikely.

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

my_storyAInspect

Your Dali creative intelligence report.

Shows your prompt scoring history across all models:

  • Total prompts scored + this month's count

  • Average score and model breakdown

  • Grade distribution (how many A, B, C, D, F scores)

  • Your creative DNA: patterns that define your highest-scoring work (V3 graph)

  • A personal insight on where you'd improve fastest

Requires login at dali.getlulu.dev. History is tied to your GitHub account.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

The description details the report contents and requires authentication (login), which informs the agent of prerequisites. No annotations are present, so the description carries the burden. It does not mention any side effects or mutability, but the tool appears read-only.

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

Conciseness4/5

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

The description is well-structured with bullet points, making it easy to parse. It is somewhat lengthy but every sentence adds value. It is front-loaded with the core purpose.

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 no parameters and the existence of an output schema, the description adequately covers all necessary context: what the tool does, what data it returns, and authentication requirements. No gaps are apparent.

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?

No parameters exist (input schema is empty), so the description does not need to add parameter meaning. It effectively describes what the tool does without needing to reference parameters.

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 it shows a 'Dali creative intelligence report' with specific elements like prompt scoring history, grade distribution, and creative DNA. It distinguishes from sibling tools by focusing on personal history and insights, making it unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for viewing personal prompt scoring history and requires login, but does not explicitly state when to use this tool over alternatives or when not to use it. No sibling differentiation is provided.

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

score_and_enhanceAInspect

Score a prompt AND get an AI-enhanced version in one call.

Combines score_prompt + enhance_prompt into a single round-trip. Returns: original score, enhanced prompt, and new score — so you can see the exact improvement before deciding which version to use.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe prompt to score and enhance
generatorYesTarget generation model (veo3, seedance, higgsfield, flux, midjourney, etc.)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

The description discloses that the tool returns three items: original score, enhanced prompt, and new score, allowing the user to see improvement. No annotations are provided, so the description carries the full burden. It does not mention any side effects, but for a non-destructive operation this is acceptable. A 5 would require mention of any irreversible changes.

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

Conciseness5/5

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

The description is four sentences, front-loaded with the core purpose, then explains the combination benefit and return values. Every sentence adds value with no wasted words.

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

Completeness4/5

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

For a tool that combines two operations, the description covers its purpose, return values, and why to use it. It does not mention limitations or prerequisites, but given the presence of an output schema, it is reasonably complete. A 5 would require additional context like rate limits or error conditions.

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?

The input schema has 100% description coverage, so the schema already describes both parameters. The description adds no extra meaning beyond listing example values for the generator parameter. Baseline 3 is appropriate.

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 'Score a prompt AND get an AI-enhanced version in one call', specifying the verb (score, enhance) and resource (prompt). It explicitly distinguishes from siblings score_prompt and enhance_prompt by combining both operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Combines score_prompt + enhance_prompt into a single round-trip', which clearly indicates when to use it (to get both operations in one call). However, it does not explicitly state when not to use it or when to prefer separate tools, so it's not a 5.

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

score_promptAInspect

Score a prompt for a specific generation model (0–100).

Returns a ScoreCard: overall score, letter grade (A–F), per-dimension breakdown, what's missing, detected anti-patterns, and a one-line verdict on whether it's safe to generate.

Supported models: veo3, seedance, kling, runway, wan, minimax, higgsfield, sora, flux, midjourney, ideogram, firefly, imagen Aliases: "veo" → veo3, "mj" → midjourney, "sd" → flux, "gen4" → runway, "hailuo" → minimax

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesTarget generation model
promptYesThe prompt to score

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the return value in detail (ScoreCard with overall, grade, breakdown, missing, anti-patterns, verdict) and lists aliases, adding behavioral context beyond the schema.

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

Conciseness5/5

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

Description is concise and front-loaded, stating purpose and return value first, then listing supported models. Every sentence adds value with no repetition or fluff.

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?

For a tool with 2 simple parameters and an output schema, the description covers purpose, return details, supported models, and aliases. It fully addresses what an agent needs to invoke correctly.

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

Parameters4/5

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

Schema coverage is 100%, but description adds value by listing supported models and aliases for the 'model' parameter. For 'prompt', it merely restates the schema. The model list is significant additional semantics.

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?

Description clearly states it scores a prompt for a generation model (0–100) and returns a detailed ScoreCard. It lists supported models and aliases, distinguishing it from siblings like score_and_enhance or score_variations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description specifies what the tool does and its return format, but does not explicitly guide when to use this tool versus alternatives like score_and_enhance or score_variations. The list of supported models provides context but lacks explicit when-not or alternative recommendations.

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

score_variationsAInspect

Score multiple prompt variations for the same generator in one call.

Returns a ranked list — highest to lowest score — so you can immediately see which variation to send to generation. Best used after writing 2–5 candidate prompts and wanting to pick the winner objectively.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptsYesList of prompt strings to compare (2–10 recommended)
generatorYesTarget generation model

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the ranked output format but omits details on scoring criteria, evaluator model, determinism, or rate limits. Acceptable but could be more transparent.

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

Conciseness5/5

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

Three concise sentences: action, output, usage advice. No fluff or redundancy. Efficient and well-structured.

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

Completeness4/5

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

Given the output schema existence and simple input requirements (2 parameters, no enums), the description covers core behavior, output, and usage. Missing edge cases or error handling, but adequate for the tool's simplicity.

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 coverage is 100% with descriptions for both parameters. The description adds the recommendation of 2–5 variations (schema says 2–10) and the 'same generator' constraint, providing marginal extra context. Baseline 3 for high coverage.

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?

Description clearly states the tool scores multiple prompt variations for the same generator in one call, returning a ranked list. This distinguishes it from siblings like score_prompt (single prompt) and score_and_enhance (scoring plus enhancement).

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?

Explicitly advises use after writing 2–5 candidate prompts to objectively pick the winner, implying it is not for single prompts or cross-generator comparisons. This provides clear when-to-use guidance and context relative to sibling tools.

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

suggest_generatorAInspect

Pick the best generation model for a creative concept + budget.

Analyzes the concept (motion, style, realism requirements) and returns a ranked list of generators with rationale and estimated cost per generation.

ParametersJSON Schema
NameRequiredDescriptionDefault
conceptYesWhat you want to create (plain language or a prompt)
budget_usd_maxNoMax spend per generation in USD (default $1.00)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, but the description discloses key behaviors: analyzes concept for motion, style, realism and returns a ranked list with rationale and cost. This is adequate for a non-destructive recommendation tool.

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

Conciseness5/5

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

Two sentences, no filler, front-loaded with the core action. Every word adds information.

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

Completeness4/5

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

Description covers input (concept, budget) and output (ranked list, rationale, cost), and output schema exists. It lacks differentiation from siblings but is sufficient given the tool's simplicity.

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

Parameters4/5

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

Schema covers both parameters fully. Description adds value by specifying that concept should include motion, style, and realism requirements, which goes beyond the schema's generic description.

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 uses specific verbs ('Pick', 'Analyzes', 'returns') and clearly indicates the tool recommends a generation model for a creative concept and budget, distinguishing it from siblings like list_models which likely only list models.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies use for recommending a model given concept and budget, but does not explicitly state when not to use it or provide alternatives among siblings.

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

track_enhancementAInspect

Record a before/after enhancement pair in the Dali graph.

Call this after you've written an enhanced prompt using the rewrite brief from enhance_prompt. This trains the community graph with real A/B data — contributing to creative_patterns and community_benchmark for all users.

ParametersJSON Schema
NameRequiredDescriptionDefault
generatorYesTarget generation model
enhanced_promptYesThe version you actually improved
original_promptYesThe un-enhanced prompt

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

Despite no annotations, the description discloses that the tool trains the community graph and contributes to creative_patterns and community_benchmark, which are significant behavioral traits. It could mention immutability or rate limits but is still informative.

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

Conciseness5/5

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

Two concise sentences with no redundancy. The first sentence states the core action, the second provides execution context and impact, earning its place.

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

Completeness4/5

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

Given the tool has an output schema (so return values are documented elsewhere), the description is complete: it specifies when to call, what it does, and the broader contribution. Minor gap: no mention of constraints like required authentication or data limits.

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 coverage is 100%, so the schema already describes all parameters. The description adds no extra meaning beyond mapping 'before/after' to original and enhanced prompts, so baseline 3 applies.

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 records a before/after enhancement pair in the Dali graph, distinguishing it from siblings like enhance_prompt (which creates the enhancement) and community_benchmark/creative_patterns (which are outcomes).

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?

Explicitly says 'Call this after you've written an enhanced prompt using the rewrite brief from enhance_prompt,' providing clear when-to-use guidance and implying not to call without prior enhancement.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 12 tool updatesv0.4.0
    • First observedanalyze_intent
    • First observedcommunity_benchmark
    • First observedcreative_patterns
    • First observeddali_version
    • First observedenhance_prompt
    • First observedlist_models
    • First observedmy_story
    • First observedscore_and_enhance
    • First observedscore_prompt
    • First observedscore_variations
    • First observedsuggest_generator
    • First observedtrack_enhancement

TDQS

A4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: analyzing intent, scoring, enhancing, benchmarking, listing models, etc. Descriptions are detailed and eliminate ambiguity.

Naming Consistency3/5

Tool names mix verb-noun (e.g., analyze_intent, score_prompt) with noun-noun or other patterns (e.g., community_benchmark, my_story), lacking a uniform convention.

Tool Count5/5

12 tools cover the full workflow of prompt optimization and community insights without redundancy or omission, perfectly scoped for the server's purpose.

Completeness5/5

The tool set provides end-to-end support for prompt analysis, scoring, enhancement, benchmarking, and tracking, with no obvious gaps for the intended domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that evaluates prompts using AI to provide detailed feedback on clarity, completeness, and effectiveness.
    5
    -
  • A
    license
    Not graded
    quality
    D
    maintenance
    This MCP server provides research-backed prompt optimization tools and professional domain templates designed to improve AI performance through strategies like Tree of Thoughts and Medprompt. It enables users to analyze, auto-optimize, and refine prompts using advanced reasoning patterns and safety-critical alignment techniques.
    24
    MIT

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/Lulu-The-Narwhal/dali-mcp'

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