Dali MCP
Dali MCP is an AI prompt optimization server that scores, analyzes, enhances, and benchmarks creative prompts for image and video generation models — helping you avoid wasted generation credits by optimizing prompts before inference.
Core Prompt Evaluation
score_prompt— Score a prompt 0–100 with a letter grade (A–F), per-dimension breakdown, detected anti-patterns, missing elements, and a verdict on whether it's safe to generateenhance_prompt— Get a structured rewrite brief (camera language, structure template, priority fixes, length targets) tailored to the target modelscore_and_enhance— Combine scoring and enhancement in one round-trip, returning the original score, enhanced prompt, and new score for comparisonanalyze_intent— Parse a prompt into structured dimensions: camera, motion, lighting, style, mood, gaps, and best-fit model suggestions
Comparison & Selection
score_variations— Rank 2–10 prompt variants for the same model, returned highest to lowest scoresuggest_generator— Recommend the best generation model for a creative concept given requirements and budget, with rationale and cost estimatescommunity_benchmark— Compare your prompt against community top-scorers, identify absent A-grade patterns, and see potential score gains
Community & History
creative_patterns— Browse community-sourced high-performing prompt patterns for a specific modeltrack_enhancement— Log before/after prompt pairs to train the community graphmy_story— View your personal scoring history, grade distribution, model breakdown, and creative DNA insights (requires login)
Utility
list_models— List all supported generation models with medium, creator, and core strengthdali_version— Check the current server version and changelogMCP Resources — Access model-specific guides via
creative://URIs
Supported Models
Video: veo3, seedance, kling, runway, wan, minimax, higgsfield, sora
Image: flux, midjourney, ideogram, firefly, imagen
Provides prompt scoring and enhancement for ByteDance's Seedance video model, optimized for UGC and social media content.
Supports prompt scoring and enhancement for Google's Veo 3.1 (and legacy Imagen) video/image models.
Supports prompt scoring and enhancement for OpenAI's Sora 2 video model (API shutdown September 24, 2026).
Provides prompt scoring and enhancement for models hosted on Replicate, including Seedance, Wan, and Minimax.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Dali MCPscore my prompt 'a flying cat' for veo3"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.serverThe 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 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 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; |
| 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 |
| 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) |
| Returns a structured rewrite brief — YOUR LLM writes the enhanced prompt. With a category, the brief is backed by real winning-ad lift |
| Record a before/after pair in the graph brain — trains community patterns |
| Rank a list of prompt variants in one call — highest to lowest |
| Pick the best model for your concept + budget |
The graph brain & meta
Tool | What it does |
| Community top patterns for this model from the graph |
| Compare your prompt against community top scorers |
| Find A/B-grade prompts that share your patterns (score the prompt first, so its patterns are in the graph) |
| Parse dimensions: camera, motion, lighting, style, mood, gaps |
| Your scoring history, model stats, grade distribution |
| All supported models with medium and core strength |
| Server version + changelog |
Supported models
Video
Model | Platforms | Best for | Prompt style |
| Higgsfield, Google AI Studio ( | Cinematic brand films, narrative ads, photorealistic motion | Camera move → Subject → Action → Location → Lighting → Mood |
| Higgsfield, fal.ai ( | UGC, social-native content, TikTok/Reels performance ads | Natural language, motion-first, authentic feel |
| Higgsfield ( | Character animation, product showcases, facial performance | Scene → Characters → Action → Camera → Style; multi-shot labels |
| Runway ( | VFX, character performance, cinematic motion | Motion-first — describe what moves, not what exists |
| fal.ai ( | 4K, 20-second clips, native audio, open-source workflows | Scene → Motion → Sound → Duration → Mood |
| fal.ai ( | Cinematic storytelling, character animation | Natural language + |
| 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 |
| BFL API ( | Photorealism, technical photography, product shots | 30–80 words; camera body + lens specs; front-load subject |
| Midjourney (v8.1) | Artistic depth, editorial, stylized illustration | Prose + params appended: |
| Ideogram API ( | Typography, logos, text-in-image, graphic design | Describe text exactly in quotes inside the prompt |
| Adobe Firefly 5 (enterprise) | IP-indemnified commercial assets, 4MP brand content | Natural language + |
Imagen 4 (Google): deprecated — use
gemini-3.5-flashwith image output. Dali still scores legacy Imagen prompts via theimagenmodel 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 |
| Google Veo 3.1 |
Higgsfield |
| ByteDance Seedance 2.0 |
Higgsfield |
| Kling 3 |
Higgsfield |
| Wan 2.7 |
Higgsfield |
| Higgsfield native |
Runway |
| Google Veo 3.1 |
Runway |
| Runway Gen 4.5 |
Runway |
| 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 ignoredIdeogram 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 overviewContributing
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 toolsanalyze_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.
| Name | Required | Description | Default |
|---|---|---|---|
| medium | No | "image", "video", or "auto" (default, auto-detected) | auto |
| prompt | Yes | Raw creative text (rough idea or full prompt — both work) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Target generation model | |
| prompt | Yes | Your prompt to benchmark |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | Minimum grade filter — "A" (only A-grade), "B" (A+B), "C" (A+B+C) | A |
| model | Yes | Target generation model (veo3, seedance, kling, runway, wan, minimax, higgsfield, flux, midjourney, ideogram, firefly) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Target generation model (veo3, seedance, kling, runway, wan, minimax, higgsfield, sora, flux, midjourney, ideogram, firefly, imagen) | |
| prompt | Yes | The prompt to enhance |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The prompt to score and enhance | |
| generator | Yes | Target generation model (veo3, seedance, higgsfield, flux, midjourney, etc.) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Target generation model | |
| prompt | Yes | The prompt to score |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| prompts | Yes | List of prompt strings to compare (2–10 recommended) | |
| generator | Yes | Target generation model |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| concept | Yes | What you want to create (plain language or a prompt) | |
| budget_usd_max | No | Max spend per generation in USD (default $1.00) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| generator | Yes | Target generation model | |
| enhanced_prompt | Yes | The version you actually improved | |
| original_prompt | Yes | The un-enhanced prompt |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
12 tool updates
v0.4.0- First observed
analyze_intent - First observed
community_benchmark - First observed
creative_patterns - First observed
dali_version - First observed
enhance_prompt - First observed
list_models - First observed
my_story - First observed
score_and_enhance - First observed
score_prompt - First observed
score_variations - First observed
suggest_generator - First observed
track_enhancement
TDQS
Each tool has a clearly distinct purpose: analyzing intent, scoring, enhancing, benchmarking, listing models, etc. Descriptions are detailed and eliminate ambiguity.
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.
12 tools cover the full workflow of prompt optimization and community insights without redundancy or omission, perfectly scoped for the server's purpose.
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
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
MCP server for Midjourney AI image generation and editing
MCP server for Wan AI video generation
MCP server for Google Veo AI video generation
MCP server for Luma Dream Machine AI video generation
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server that evaluates prompts using AI to provide detailed feedback on clarity, completeness, and effectiveness.5-
- AlicenseBqualityDmaintenanceAn MCP server that automatically optimizes AI prompts using evolutionary algorithms, helping improve prompt performance, creativity, and reliability through iterative testing and refinement.123MIT
- AlicenseNot gradedqualityDmaintenanceThis 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.24MIT
- AlicenseAqualityDmaintenanceMCP server for community-driven prompt voting and discovery — submit, upvote, and find the best AI prompts.7MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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