Skip to main content
Glama
nbhson

Universal Prompt Gate MCP Server

by nbhson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Prompt Rewrite (no approval)

rewrite_prompt

Enrich a user prompt with context, structure, and quality criteria to create a candidate rewrite for review; it never approves or forwards the result.

Instructions

Re-emit the given prompt with richer context, structure, and quality criteria. This tool only produces a candidate rewrite; it does NOT approve the result. Use review_and_select_prompt for the gated, user-confirmed flow.

CALLING GUIDE (for the LLM):

  • ALWAYS pass a short context (1-3 sentences) summarizing the conversation/session so far so the enrichment is grounded. Do not omit it.

  • Choose rewrite_level to fit the task: light for quick one-shot answers, balanced (default) for most coding/research work, detailed when the user explicitly wants a fully-specified spec.

  • Pass language only when the user wants the rewritten prompt in a language different from the original. Do NOT switch the language on your own judgment — the server auto-detects the prompt language and preserves it by default.

Input Schema

NameRequiredDescriptionDefault
promptYesThe original prompt to rewrite. This is the user's latest message only.
contextYes1-3 sentences summarizing the conversation/session so far (what the user has asked, what files/topics are in play, what was decided). STRONGLY RECOMMENDED: pass this on every call so the rewrite is grounded in prior context. Omit only for brand-new sessions with no history.
languageNoOutput language, e.g. "english" or "vietnamese". ONLY pass this when the user explicitly asks for a different output language. If the user has not asked, omit it — the server auto-detects the prompt's language and preserves it. Do NOT pass "english" just to "improve clarity"; that switches the output language and is a drift.
rewrite_levelNoHow much enrichment to apply. "light" = minimal (keep close to original); "balanced" (default) = add missing structure/context/criteria; "detailed" = full spec with acceptance criteria. Pick based on task complexity.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose key behavior: it only produces a candidate rewrite and does NOT approve the result. It also warns about the language-drift risk and server-side auto-detection. It stops short of describing output shape or side effects in detail, but the mutation-vs-read semantics are clear.

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

Conciseness5/5

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

Front-loads the core purpose and the key exclusion in the first two sentences, then uses a compact bulleted calling guide. Every sentence earns its place; no filler.

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

Completeness4/5

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

For a generation tool with no output schema and no annotations, the description covers purpose, the non-approval behavior, and per-parameter usage. It doesn't describe the return payload, but the 'candidate rewrite' framing makes the outcome clear enough.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it maps rewrite_level values to task types (light/balanced/detailed), states context is grounded session history, and gives a strong warning about language drift. This goes beyond restating the schema descriptions.

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

Purpose5/5

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

States a specific verb+resource ('Re-emit the given prompt with richer context, structure, and quality criteria') and explicitly distinguishes itself from the sibling by naming review_and_select_prompt for the gated flow. The title reinforces the 'no approval' scope, so an agent can tell the two prompt tools apart immediately.

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

Usage Guidelines5/5

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

The CALLING GUIDE gives explicit when/when-not guidance: always pass context, choose rewrite_level by task type, and only pass language when the user asks. It also names the alternative tool and the condition that selects it ('gated, user-confirmed flow'), leaving nothing to inference.

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

Deploy Server

Other Tools