Universal Prompt Gate MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROMPT_GATE_ENV_FILE | No | Explicit path to a .env file | |
| PROMPT_GATE_PROVIDER | No | openai-compatible / openai / custom | openai-compatible |
| PROMPT_GATE_LLM_MODEL | No | Model name | qwen3.5-9b |
| PROMPT_GATE_TRANSPORT | No | stdio or http | stdio |
| PROMPT_GATE_TIMEOUT_MS | No | LLM timeout in ms (thinking models on CPU need more time) | 180000 |
| PROMPT_GATE_LLM_API_KEY | No | API key (for local dev, no real key needed) | local-dev-key |
| PROMPT_GATE_EXTERNAL_LLM | No | Optional: cloud LLM endpoint | |
| PROMPT_GATE_LLM_BASE_URL | No | LLM endpoint (OpenAI-compatible) | http://127.0.0.1:8080/v1 |
| PROMPT_GATE_ECHO_FALLBACK | No | When the client does not support MCP elicitation, the gate tool returns a pending_user_selection text menu instead of a hard error (agent re-calls with selection) | true |
| PROMPT_GATE_LLM_RETRY_MAX | No | Retry count for network errors (idempotent calls only) | 3 |
| PROMPT_GATE_LLM_EXTRA_JSON | No | JSON object merged into the LLM request body (e.g. {"chat_format":"chatml"}) | |
| PROMPT_GATE_LLM_MAX_TOKENS | No | Max completion tokens (thinking models need a larger budget) | 2048 |
| PROMPT_GATE_LLM_ENABLE_THINKING | No | true/false — enable/disable reasoning (qwen3 / llama.cpp thinking models) | |
| PROMPT_GATE_REWRITE_POLICY_FILE | No | Custom meta-prompt policy file (presets: news/code/research, …) — overrides the default strategy | |
| PROMPT_GATE_CUSTOM_PROVIDER_MODULE | No | Path to a custom provider module (only used when provider=custom) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rewrite_promptA | 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):
|
| review_and_select_promptA | Generates a rewritten version of the prompt, then asks the user to choose: use original, use rewritten, or cancel. Returns only the approved prompt. Cancellation is a distinct outcome and never exposes an approved prompt. If the client does not support MCP elicitation, the tool returns a distinct "pending_user_selection" result: it shows both versions in plain text with the three numbered choices and asks the agent to re-call this tool with CALLING GUIDE (for the LLM):
|
| get_client_capabilitiesA | Reports which interaction features are available for the current MCP client/session: elicitation support, structured elicitation, transport, integration mode, and whether a mandatory prompt gate is enforceable. Capabilities are derived from verified protocol negotiation, not from the agent name. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
get_client_capabilities is clearly distinct as a capability probe. rewrite_prompt and review_and_select_prompt overlap in that both generate rewritten prompts, but the descriptions explicitly draw the line: rewrite_prompt produces an unapproved candidate while review_and_select_prompt runs the gated, user-confirmed flow. The boundary is documented, so misselection is unlikely but not impossible.
All names use snake_case with verb-first phrasing (get_*, rewrite_*, review_and_select_*), which is readable and mostly uniform. review_and_select_prompt is a compound verb phrase rather than a simple verb_noun, a minor deviation from the otherwise consistent pattern.
Three tools is a lean surface but each maps to a distinct stage of the workflow: capability discovery, candidate rewrite, and gated approval/selection. The count is slightly thin but well-scoped and nothing feels redundant or padded.
The lifecycle for a prompt-gate server is largely covered: negotiate capabilities, generate a rewrite, and handle user approval including a documented fallback for clients without elicitation. Minor gaps exist around configuration or non-elicitation batch handling, but core agent workflows are supported without dead ends.