The Prompt Enhancer MCP server uses a local or cloud LLM to rewrite rough prompt drafts into structured, optimized prompts — saving tokens and improving output quality when using paid APIs. It provides five core tools:
optimize_prompt: Rewrites a rough draft via a self-critique pipeline (draft → critique → refine). Supports target model formats (Claude, GPT-4o, Gemini, generic), multi-persona brainstorming, automatic enhancements (Chain-of-Thought, guardrails, intent classification), session-based iteration, configurable verbosity, in-memory response caching, auto-context scanning of local project files, and interactive approval mode.
lint_prompt: Statically checks any prompt (no LLM call) for unresolved {{placeholders}}, suspect acronym expansions (validated against a glossary if configured), and leaked meta-commentary.
score_prompt: Grades a prompt 1–5 across five dimensions — clarity, specificity, structure, guardrails, and token efficiency. Supports comparison mode with per-dimension deltas between two prompts.
generate_system_prompt: Drafts a complete system prompt for a given agent role, with automatic lint and score. Supports failure mode guardrails, diagnosis from conversation transcripts, terse vs. guardrailed variants (rigor: "both"), and multiple output formats (plain, XML, Markdown, JSON).
check_health: Verifies the configured LLM engine is reachable and the target model is available.
Engine support: Local/remote Ollama (Llama 3, Mistral, Qwen, etc.), Anthropic API (Claude), or MCP Sampling (delegates to the connected client's model). Project-wide defaults can be set via a .prompt-enhancer.json file.
Allows optimizing prompts for Google’s Gemini API, generating structured prompts using XML tags as per Google's guidance.
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., "@Prompt Enhancer MCP enhance this draft for Claude: 'write a blog post about AI'"
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.
Local MCP server that uses a local Ollama model as a "Prompt Engineer" to rewrite rough prompt drafts into structured, optimized prompts before you send them to a paid API (Claude, GPT-4o, etc.) — saving tokens and improving output quality on the paid model.
Every request runs a self-critique pipeline (generate a first draft, then have the local model critique and refine it) unless the draft is trivial enough to skip the critique pass. Optional features layer on top: multi-persona brainstorming, a 1-line summary of what the critic changed, an in-memory response cache, and per-project default presets.
Model Agnostic: The server supports both local execution via Ollama (Llama 3, Mistral, Qwen, Phi, etc.) and cloud execution via the Anthropic API (Claude 3.5 Haiku, Sonnet, etc.). You can configure the engine and model per project or per request!
Input (draft):
quero um resumo do texto mas curtoOutput (optimize_prompt result):
Please provide a short, concise summary of the following text.
Focus only on the main points and key information—omit minor
details or repetition. Keep the summary brief (2-4 sentences).The rough, ambiguous draft becomes a structured, unambiguous instruction the paid model can execute correctly on the first try — no back-and-forth, no wasted tokens on a misinterpreted request.
Related MCP server: ollama-mcp
Register the server with your MCP client — see Register with an MCP client below. The fastest path is Claude Desktop or Claude Code with the npx config; no cloning or building required.
Have Ollama running locally with a model pulled (see Prerequisites), or set ANTHROPIC_API_KEY instead.
In your MCP client, call check_health to confirm the engine is reachable.
Call optimize_prompt with a rough draft (see example above) and use the result.
If step 3 reports a problem, see Troubleshooting.
Node.js 20+
Option A (Local Ollama): Ollama running locally with a model pulled, e.g.:
ollama pull qcwind/qwen2.5-7B-instruct-Q4_K_MOption B (Remote Ollama): Ollama running on a machine you control (e.g. a home server exposed through a tunnel), with OLLAMA_BASE_URL (and optionally OLLAMA_EXTRA_HEADERS for an authenticating proxy) pointed at it. See Remote Ollama endpoint below. Useful when local model execution isn't available on your machine (e.g. a locked-down company laptop).
Option C (Cloud): An Anthropic API Key (ANTHROPIC_API_KEY environment variable). Useful when neither local nor remote Ollama is an option.
If you want to clone and modify the server locally:
npm install
npm run build
npm testnpm run build compiles src/ to dist/index.js. You can then run it via node dist/index.js.
The package ships a global mcp command that you can use from the terminal.
See the full reference in docs/cli.md.
If you use Claude Code, run mcp skills install to add the bundled
draft-prompt skill (a guided interview that builds a structured prompt
before calling optimize_prompt for you):
mcp skills installThen, in any Claude Code session with this MCP server registered, type
/draft-prompt to run it. See
docs/cli.md#mcp-skills-install for install
options (e.g. --project).
You do not need to clone the repository to use this MCP server. You can run it directly via npx.
All MCP clients register a server the same way. Below are the exact config file and key for each client this server has been used with.
Edit claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"prompt-enhancer": {
"command": "npx",
"args": [
"-y",
"--package=@nuno-morais/prompt-enhancer-mcp@latest",
"prompt-enhancer-mcp"
]
}
}
}Restart Claude Desktop for the change to take effect.
Add the same block to Claude Code's MCP settings (.claude/settings.json or via claude mcp add, depending on your Claude Code version):
{
"mcpServers": {
"prompt-enhancer": {
"command": "npx",
"args": [
"-y",
"--package=@nuno-morais/prompt-enhancer-mcp@latest",
"prompt-enhancer-mcp"
]
}
}
}Both use the same config file and key: ~/.gemini/settings.json.
{
"mcpServers": {
"prompt-enhancer": {
"command": "npx",
"args": [
"-y",
"--package=@nuno-morais/prompt-enhancer-mcp@latest",
"prompt-enhancer-mcp"
]
}
}
}If the file already has an "mcpServers" object with other servers in it,
add "prompt-enhancer" as a new key inside it rather than replacing the file.
Restart the CLI session after editing.
Navigate to Cursor Settings -> Features -> MCP -> Add new MCP server.
Name: prompt-enhancer
Type: command
Command: npx -y --package=@nuno-morais/prompt-enhancer-mcp@latest prompt-enhancer-mcp
Click "Add" and ensure the green light indicates a successful connection.
Since this tool uses the standard Model Context Protocol, it can be connected to any IDE or agent that acts as an MCP client. If your client requires a JSON configuration (like Zed or PI.dev configurations), the pattern is typically the same:
{
"mcpServers": {
"prompt-enhancer": {
"command": "npx",
"args": [
"-y",
"--package=@nuno-morais/prompt-enhancer-mcp@latest",
"prompt-enhancer-mcp"
]
}
}
}If your client provides a UI to add tools instead of a configuration file, use the equivalent shell command: npx -y --package=@nuno-morais/prompt-enhancer-mcp@latest prompt-enhancer-mcp.
The server exposes five tools: optimize_prompt, lint_prompt, score_prompt, generate_system_prompt, and check_health.
Optimizes a rough prompt draft using a local LLM before sending it to a paid API.
{
"draft": "quero um resumo do texto mas curto",
"context": "MCP in this project means Model Context Protocol server",
"target_model": "claude",
"brainstorm": false,
"session_id": "my-iteration-1",
"auto": true,
"verbosity": "quiet",
"engine": "ollama",
"model": "llama3.1:8b"
}Only draft is required — every other field has a default.
Checks any prompt for common issues without making LLM calls. Detects unresolved placeholders ({{placeholder}}), suspect acronym expansions (against the glossary), and leaked meta-commentary.
{
"prompt": "Here is the optimized prompt.",
"draft": "Original draft text (optional; enables draft-comparison rules)",
"context": "Background context (optional)"
}Only prompt is required. When draft is provided, lint runs acronym expansion checks.
Judge-grades a prompt 1-5 on five dimensions: clarity, specificity, structure, guardrails, and token efficiency. Pass baseline to switch to comparison mode.
{
"prompt": "The prompt to score",
"baseline": "Optional second prompt for comparison mode",
"engine": "ollama",
"model": "llama3.1:8b"
}Only prompt is required. Comparison mode shows per-dimension deltas and a winner verdict.
Drafts a system prompt for a given agent role, then auto-lints and auto-scores it before returning. Pass rigor: "both" to generate a terse and a guardrailed variant and get a judged head-to-head comparison.
{
"role": "senior code reviewer",
"failure_modes": ["hallucinates file paths", "too verbose"],
"transcript": "Optional failed-conversation excerpt to diagnose from",
"rigor": "guardrailed",
"format": "xml",
"engine": "ollama",
"model": "llama3.1:8b"
}Only role is required. rigor is "terse", "guardrailed" (default), or "both"; format is "plain" (default), "xml", "markdown", or "json".
Checks whether the configured LLM engine is reachable and ready to use — including whether the connected MCP client supports the sampling engine. Takes optional engine and model arguments; with no arguments it checks the configured/preset engine.
Field | Type | Default | Description |
| string | — (required) | The rough idea to turn into an optimized prompt. |
| string | — | Background/domain context (project description, glossary, relevant facts) used to interpret domain-specific terms in the draft. |
| boolean |
| Automatically scan the local project (package.json, git) for context and append it to any |
|
|
| Which API/format the optimized prompt is written for — |
| boolean |
| When true, the optimized prompt instructs the target model to answer via multiple distinct personas/perspectives (useful for open-ended ideation). |
|
|
| How much detail comes back with the prompt: |
| boolean |
| Master switch for the automatic enhancement passes: Chain-of-Thought injection ( |
| boolean |
| When true, instructs the MCP client NOT to answer the optimized prompt immediately, but instead present it to the user for approval. |
|
|
| Choose the backend engine. If using |
| string |
| Override which model runs the pipeline. If |
The legacy fine-grained booleans (auto_cot, auto_guardrails, auto_intent,
auto_repair, explain, show_stats, show_diff) are still accepted, both as
tool arguments and in .prompt-enhancer.json, and override auto/verbosity
per flag.
The response is an MCP content array: one text block with the optimized
prompt, plus extra text blocks depending on verbosity.
By default, the server talks to Ollama at http://localhost:11434. To point it at a remote Ollama instance instead — for example, one exposed through a Cloudflare Tunnel or reverse proxy from a machine you control — set:
OLLAMA_BASE_URL — the base URL of the remote Ollama instance, e.g. https://your-ollama-host.example.com. Defaults to http://localhost:11434.
OLLAMA_EXTRA_HEADERS — a JSON object of extra HTTP headers to send with every Ollama request, e.g. {"CF-Access-Client-Id":"...","CF-Access-Client-Secret":"..."} if the endpoint sits behind an authenticating proxy such as Cloudflare Access. Defaults to no extra headers.
For the MCP server itself, set these in the env block of your MCP host's server configuration (e.g. .mcp.json):
{
"mcpServers": {
"prompt-enhancer": {
"command": "prompt-enhancer-mcp",
"env": {
"OLLAMA_BASE_URL": "https://your-ollama-host.example.com",
"OLLAMA_EXTRA_HEADERS": "{\"CF-Access-Client-Id\":\"...\",\"CF-Access-Client-Secret\":\"...\"}"
}
}
}
}For the standalone mcp CLI tool, use flags instead (these take precedence over the env vars above):
mcp --draft "quick note" --ollama-url https://your-ollama-host.example.com \
--ollama-header "CF-Access-Client-Id=..." \
--ollama-header "CF-Access-Client-Secret=..."The sampling engine is an optional third choice that uses the connected MCP client's own model via MCP sampling, instead of Ollama or Anthropic. It is opt-in only — set engine: "sampling" in your .prompt-enhancer.json preset or pass it to the MCP tool directly. The connected MCP client must advertise the sampling capability for this to work.
Important: the sampling engine is not available from the CLI. If you try to use --engine sampling with the mcp command-line tool, it will exit with an error. Use it only when calling optimize_prompt as an MCP tool from a supporting client (Claude Desktop, Claude Code, etc.).
You can check if the connected client supports sampling by calling the check_health tool — it will report whether the capability is available.
Self-critique pipeline: every non-trivial request makes 2 Ollama calls
(draft, then critique/refine); verbosity: "explain" or "verbose" adds a 3rd. A trivial draft
(target_model: "generic", brainstorm: false, ≤15 words) skips the
critique call entirely — 1 call instead of 2.
Output lint: every response is checked (no extra LLM calls) for
unresolved {{placeholders}}, acronym expansions not supported by your
draft/context, and leaked meta-commentary. Problems are appended as a
⚠️ Prompt lint warnings block instead of silently shipping a broken prompt.
Auto-repair: part of the auto passes (on by default): optimize_prompt automatically fixes repairable lint findings (such as wrong acronym expansions covered by your glossary) with one extra critic pass. Unfixable findings are still surfaced as warnings. Disable it with auto: false (or the legacy auto_repair: false / --no-auto-repair CLI flag to turn off just this pass).
Response cache: identical requests (same draft, context,
target_model, brainstorm, engine, model, and output settings) are
cached in memory for 1 hour (100-entry LRU). A cache hit returns instantly
with zero LLM calls.
Intent classification: unless disabled (auto: false or the legacy
auto_intent: false), classification tags
each draft as needing web search, a user-provided artifact, brainstorming,
or nothing. It runs in parallel with the first draft when brainstorm is
explicitly set; when brainstorm is left unset (the default), it runs
sequentially before the first draft, since its result determines whether
brainstorm mode is used. Web-search/artifact intents add one instruction
line to the optimized prompt; an ideation draft auto-enables brainstorm mode
when you didn't set brainstorm yourself. Explicit brainstorm (argument
or preset) always wins. Wrong classifications are harmless: the line is
advisory prose, and any failure falls back to injecting nothing. Session
(session_id) refinement calls never re-classify.
Project presets: drop a .prompt-enhancer.json file anywhere in your
project (the server searches upward from its working directory to find
it, like .eslintrc) to set project-wide defaults.
For Ollama:
{ "target_model": "claude", "verbosity": "verbose", "model": "mistral" }For Anthropic (e.g. upgrading from Haiku to Sonnet):
{ "engine": "anthropic", "model": "claude-3-5-sonnet-latest", "target_model": "claude", "verbosity": "verbose" }With a glossary (authoritative term definitions for lint and auto-repair):
{ "target_model": "claude", "verbosity": "explain", "glossary": { "MCP": "Model Context Protocol", "LLM": "Large Language Model" } }Any parameter can be set this way. An explicit argument in a tool call always overrides the preset.
Glossary: the glossary key lets you define authoritative meanings for acronyms and terms in your project. When set, lint_prompt will flag acronym expansions that don't match the glossary, and optimize_prompt with auto_repair: true (the default) will automatically fix wrong expansions on a second pass. Example: {"glossary": {"MCP": "Model Context Protocol"}}.
Diff view: verbosity: "verbose" appends a line diff showing exactly what
the self-critique pass changed between the first draft and the final
prompt. Computed locally — no extra LLM calls. For trivial drafts (critic
skipped) it reports that no diff is available.
Background Processes (Zero-Cost Latency): the Chain-of-Thought and guardrail auto passes are executed asynchronously in parallel with the first draft generation, causing zero extra wait time.
Progress notifications: if your MCP client attaches a progressToken
to its tools/call request, the server sends notifications/progress
updates as the pipeline advances through its stages. Clients that don't
ask for this see no behavior change.
Domain context: pass context with a sentence or two of background
(glossary, project description) whenever the draft contains ambiguous or
domain-specific terms. The local model uses it only to interpret the draft
— it is never rewritten into the output. Without it, small local models
will guess what acronyms mean.
Iterating on a prompt: pass a session_id on the first call, then call
again with the same session_id and your feedback as the new draft
("make it shorter", "the MCP here is Model Context Protocol"). The server
keeps the conversation and refines the previous prompt instead of starting
over. Session requests always bypass the response cache.
Call check_health first — it diagnoses the configured engine and reports the fix directly. Common cases:
Symptom | Cause | Fix |
| Ollama isn't running | Run |
| The configured model isn't installed | Run |
|
| Set |
| Sampling only works through an MCP client | Use it via |
Optimized prompt has a | The critic pass left an unresolved placeholder, an unsupported acronym expansion, or leaked meta-commentary | Re-run with more |
test-manual.sh drives the server over raw JSON-RPC on stdio (MCP doesn't
speak HTTP, so curl won't work here):
./test-manual.sh "<draft>" [target_model] [brainstorm] [explain]Examples:
# Defaults (generic, no brainstorm, no explain)
./test-manual.sh "quero um resumo curto do texto"
# Claude-formatted, with the change-summary block
./test-manual.sh "I want a detailed and comprehensive summary of this long article covering many different topics in depth" claude false true
# Brainstorm mode
./test-manual.sh "preciso de ideias para o nome de uma nova cafetaria" generic trueChecks whether the configured LLM engine (Ollama or Anthropic) is reachable and ready to use
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Override for the model to check availability for (Ollama only). Defaults to the configured/preset model. | |
| engine | No | The engine to check (ollama or anthropic). Defaults to the configured/preset engine. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes the action but does not disclose whether it is read-only, idempotent, or has side effects. For a health check, no side effects are expected, but this is implicit.
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 a single sentence, front-loaded with the core purpose, and contains no unnecessary words or redundancy.
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 output schema, the description should clarify what the return value looks like (e.g., boolean, health status). It names the engines but fails to explain the expected output format, which is a minor gap.
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 description adds no new parameter meaning beyond what the schema already provides (e.g., 'model' override and 'engine' selection are fully described in the schema). 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 it checks if the configured LLM engine (Ollama or Anthropic) is reachable and ready. It specifies the verb 'checks' and the resource 'LLM engine', and distinguishes from the sibling tool 'optimize_prompt' by focusing on health status rather than prompt optimization.
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 verifying engine availability, which is clear context. However, it does not explicitly state when not to use or mention alternatives, though the sibling tool is conceptually distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drafts a system prompt for a given role, then auto-lints and auto-scores it before returning. Pass rigor: 'both' to generate a terse and a guardrailed variant and get a judged comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | The agent's role/task, e.g. 'senior code reviewer' | |
| model | No | Override for the model | |
| rigor | No | 'both' generates a terse and a guardrailed variant and judges them head-to-head | guardrailed |
| engine | No | The underlying LLM engine to use | |
| format | No | Output format for the generated prompt(s) | plain |
| transcript | No | Optional failed-conversation excerpt to diagnose from instead of a cold role | |
| failure_modes | No | Optional known failure modes to guard against (e.g. 'hallucinates file paths', 'too verbose') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behavior: drafting then auto-linting and auto-scoring. However, it does not detail other aspects like return format or authentication needs. The 'rigor' behavior is explained, but overall transparency is adequate yet not comprehensive.
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: first sentence covers the core purpose and auto-validation, second explains the key 'rigor' option. No filler, every sentence adds value. Ideal conciseness.
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 7-parameter tool with no output schema, the description is somewhat minimal. It does not describe what the returned output looks like (e.g., combined prompt with scores) or mention optional parameters like transcript or failure_modes. Adequate but not complete.
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 baseline is 3. The description adds minimal new meaning beyond the schema; it repeats the 'both' option explanation already present in the schema's description. The role parameter is mentioned generally.
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 drafts a system prompt for a role and then auto-lints and auto-scores it. It uses a specific verb 'Drafts' and distinguishes itself from sibling tools (lint_prompt, score_prompt) by combining these steps in one call.
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 the tool is an all-in-one for generating and evaluating prompts but does not explicitly state when to use it versus sibling tools. No alternatives or exclusions are mentioned, leaving guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks any prompt for common issues (unresolved placeholders, suspect acronym expansions, leaked meta-commentary). No LLM call.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | Optional original draft; enables draft-comparison rules (e.g. acronym expansion checks) | |
| prompt | Yes | The prompt to lint | |
| context | No | Optional background context the prompt was built from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions no LLM call and lists check categories, but does not disclose return format, side effects (none expected but not stated), or any required privileges. The behavior is partially 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?
Two sentences, front-loaded with purpose and examples, no redundant information. Every word earned 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 low complexity (3 params, no nested objects), the description covers the what and broad categories but lacks information about output format (e.g., list of issues). With no output schema, return value should be described for completeness.
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 baseline is 3. The description adds marginal value by explaining how draft enables comparison rules and context provides background, but the prompt parameter is simply restated. No additional formats or constraints beyond 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?
The description clearly states the tool checks prompts for common issues, listing specific categories (unresolved placeholders, suspect acronym expansions, leaked meta-commentary). It distinguishes from sibling tools as a linting tool, with a clear verb and resource.
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 pre-checking prompt quality before finalizing, but does not explicitly state when to use vs alternatives or when not to use. The 'No LLM call' hint is useful but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optimizes a rough prompt draft using a local LLM before sending it to a paid API
| Name | Required | Description | Default |
|---|---|---|---|
| auto | No | Master switch for all automatic enhancement passes: Chain-of-Thought injection, anti-hallucination guardrails, intent classification, and lint auto-repair. The legacy auto_cot/auto_guardrails/auto_intent/auto_repair booleans are still accepted and override this per pass. | |
| draft | Yes | The raw draft idea | |
| model | No | Override for the model | |
| engine | No | The underlying LLM engine to use | |
| context | No | Optional background/domain context (project description, glossary, relevant facts) to help the model correctly interpret domain-specific terms in the draft | |
| verbosity | No | How much detail to return alongside the optimized prompt: 'quiet' = prompt only, 'explain' = plus a 1-line summary of what the critic pass changed, 'verbose' = plus token stats and a critic-pass diff. The legacy explain/show_stats/show_diff booleans are still accepted and override this. | quiet |
| brainstorm | No | When true, instructs the target model to generate multiple personas/perspectives for open-ended brainstorming | |
| session_id | No | Optional ID to maintain conversation state. Provide a unique string. When making tweaks to a previously generated prompt, pass the same session_id. | |
| interactive | No | When true, instructs the calling assistant to pause and ask for user approval before answering the optimized prompt. Defaults to true to allow iteration. | |
| auto_context | No | Automatically scan the local project (package.json, git) for context to append to the prompt. | |
| target_model | No | The target API/format this prompt will be sent to | generic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool uses a local LLM (free, no external cost) and modifies the prompt, but it does not disclose potential resource usage, rate limits, or side effects. The description is adequate but lacks depth.
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 a single sentence that is concise and front-loaded. It earns its place, but could be slightly more informative without being verbose.
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 tool has 11 parameters and no output schema or annotations. The description does not explain return values, the optimization process, or when to use specific parameters. It provides a high-level overview but lacks the detail needed for complete understanding.
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?
All 11 parameters are described in the schema (100% coverage), so the description does not need to add meaning. It adds no further explanation beyond the schema. Baseline score of 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 the tool's function: it optimizes a rough prompt draft using a local LLM. It also provides context (before sending to a paid API) that distinguishes it from sibling tools like check_health, generate_system_prompt, lint_prompt, and score_prompt.
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 preparing prompts for paid APIs to reduce costs, but it does not explicitly state when to use this tool versus alternatives like lint_prompt or generate_system_prompt. No exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Judge-grades a prompt 1-5 on clarity, specificity, structure, guardrails, and token efficiency. Pass 'baseline' to compare two prompts and get per-dimension deltas and a verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Override for the judge model | |
| engine | No | The underlying LLM engine to use | |
| prompt | Yes | The prompt to score | |
| baseline | No | Optional second prompt; switches to comparison mode (baseline vs prompt) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions scoring dimensions, comparison mode, and output (deltas/verdict) but lacks details on side effects, auth, or rate limits. For a non-destructive scoring tool, this is adequate but not comprehensive.
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, efficient and front-loaded with the core purpose. Every sentence adds value with no redundancy.
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?
No output schema is provided, so the description should clarify return format. It mentions grades 1-5 and deltas/verdict for comparison, but lacks specifics on output structure (e.g., JSON with per-dimension scores). For a tool with 4 parameters and no output schema, this is a notable gap.
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 baseline is 3. The description adds context about the baseline parameter switching to comparison mode and mentions per-dimension deltas and verdict, which enriches understanding beyond the 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?
The description clearly states the tool grades a prompt on five specific dimensions with a 1-5 scale and has a comparison mode with baseline. It distinguishes itself from siblings like lint_prompt or optimize_prompt by focusing on scoring.
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 scoring prompts but does not explicitly advise when to use this tool over siblings. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.14.0generate_system_promptlint_promptoptimize_prompt9 fields changedInput schema / properties / autoAdded value: +{
+ "default": true,
+ "description": "Master switch for all automatic enhancement passes: Chain-of-Thought injection, anti-hallucination guardrails, intent classification, and lint auto-repair. The legacy auto_cot/auto_guardrails/auto_intent/auto_repair booleans are still accepted and override this per pass.",
+ "type": "boolean"
+}Input schema / properties / auto_contextAdded value: +{
+ "default": false,
+ "description": "Automatically scan the local project (package.json, git) for context to append to the prompt.",
+ "type": "boolean"
+}Input schema / properties / auto_cotRemoved value: -{
- "default": true,
- "description": "Automatically inject Chain-of-Thought (CoT) instructions if the task is complex.",
- "type": "boolean"
-}Input schema / properties / auto_guardrailsRemoved value: -{
- "default": true,
- "description": "Automatically generate and inject negative constraints (anti-hallucination guardrails).",
- "type": "boolean"
-}Input schema / properties / engine / descriptionPrevious value: -"The underlying LLM engine to use (ollama or anthropic)"New value: +"The underlying LLM engine to use"Input schema / properties / engine / enumAdded value: +[
+ "ollama",
+ "anthropic",
+ "sampling"
+]Input schema / properties / explainRemoved value: -{
- "default": false,
- "description": "When true, includes a 1-line summary of what the critic pass changed, as a second content block",
- "type": "boolean"
-}Input schema / properties / show_statsRemoved value: -{
- "default": false,
- "description": "Show a token count and prompt efficiency analysis.",
- "type": "boolean"
-}Input schema / properties / verbosityAdded value: +{
+ "default": "quiet",
+ "description": "How much detail to return alongside the optimized prompt: 'quiet' = prompt only, 'explain' = plus a 1-line summary of what the critic pass changed, 'verbose' = plus token stats and a critic-pass diff. The legacy explain/show_stats/show_diff booleans are still accepted and override this.",
+ "enum": [
+ "quiet",
+ "explain",
+ "verbose"
+ ],
+ "type": "string"
+}score_promptv0.1.0check_healthoptimize_promptEach tool has a clearly distinct purpose: health check, system prompt generation, linting, optimization, and scoring. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to distinguish.
With 5 tools, the server covers the essential prompt enhancement workflows without being too sparse or bloated.
The tool set covers health checks, generation, linting, optimization, and scoring. Minor gaps exist, such as no dedicated template management tool, but core operations are well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for generating rough-draft project plans from natural-language prompts.
Cloudflare Workers MCP server: ai-prompt-optimizer
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nuno-morais/prompt-enhancer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
