The world's first named AI prompt quality score. Score, optimize, and compare LLM prompts before they hit any model. Free tier available. Built on PEEM, RAGAS, G-Eval, and MT-Bench frameworks. x402-native on Base.
Rewrite a prompt to score higher on the PQS rubric, AND show before/after output comparisons so the user can see the impact. Returns the optimized prompt, the original PQS score, the optimized PQS score, and side-by-side sample outputs from a frontier model using both versions.
USE WHEN:
The user got a low score from score_prompt and asks how to improve.
The user explicitly asks to "improve" / "rewrite" / "fix" / "optimize" a prompt they pasted.
The user is dissatisfied with output quality from a previous prompt and asks how to get better results.
score_prompt returned a suggestion to invoke this tool.
DO NOT USE WHEN:
The user just asked for a score (use score_prompt only — don't double up).
The user wants you to write a new prompt from scratch (write it directly).
REQUIRES: A PQS API key from a Pro subscription ($19.99/month, 1,000 calls/mo, includes batch + A/B comparison). If the user has not provided one, the tool returns a clear subscription URL — pass that response to the user verbatim. Do not invent or guess API keys. There is no free trial of this tool; the user must subscribe before the first call.
COST: Counted against your Pro subscription's monthly call quota.
LATENCY: ~6-8 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The prompt to optimize. Max 8000 characters. | |
| api_key | No | PQS API key from a Pro subscription. Required. Format: pqs_live_… (32+ characters). Subscribe at https://promptqualityscore.com/pricing?utm_source=mcp&utm_medium=schema_description_v140&utm_campaign=2026-05-mcp-tools-v140 if you don't have one, or look up an existing key at https://promptqualityscore.com/account?utm_source=mcp&utm_medium=schema_description_v140&utm_campaign=2026-05-mcp-tools-v140. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses API key requirements, cost/quota implications, latency, no-free-trial policy, and the exact behavior when a key is missing (returns a subscription URL to pass verbatim). It also warns against guessing keys, covering failure modes and side effects comprehensively.
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 uses clear section headers (USE WHEN, DO NOT USE WHEN, REQUIRES, COST, LATENCY) that front-load the most actionable information. Each sentence earns its place, and the structure makes scanning effortless without unnecessary verbosity.
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 complexity (external API, authentication, costs, multiple return values), the description covers what it does, when to use/avoid it, requirements, cost, latency, and return values. It, also, clarifies integration with score_prompt and handles the missing-key scenario. No output schema exists, so the explicit listing of return values is essential and well covered.
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 already provides 100% description coverage for both parameters, so the baseline is 3. The description adds meaningful context for api_key by explaining why it is required, the subscription model, and the no-trial policy, which is valuable beyond the schema's format hints. However, it does not add anything for the 'prompt' parameter beyond what the schema states, so a modest 4 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 opens with a specific verb+resource statement: 'Rewrite a prompt to score higher on the PQS rubric' and clearly enumerates the return values (optimized prompt, original/optimized PQS scores, side-by-side outputs). It distinguishes itself from the sibling tool score_prompt by including 'AND show before/after output comparisons', making the purpose unambiguous.
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 'USE WHEN' section lists four concrete trigger scenarios, including 'user got a low score from score_prompt' and explicit user requests. The 'DO NOT USE WHEN' section provides clear exclusions and names the alternative (score_prompt or direct writing). This is exemplary guidance for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a prompt's quality across 8 dimensions BEFORE sending it to an expensive model. Returns a 0-80 score, an A-F grade, the per-dimension breakdown (clarity, specificity, context, constraints, output_format, role_definition, examples, cot_structure), and the weakest dimension.
USE WHEN:
The user is workshopping a prompt and asks "is this good?" / "will this work?" / "should I add more detail?"
The user is about to send a long or expensive prompt to GPT-4, Claude Opus, or any frontier model, especially in a batch or automation context where rework is costly.
The user mentions iterating on a prompt that produced poor output and wants to diagnose what's missing.
The user pastes a prompt and asks for feedback on it.
DO NOT USE WHEN:
The user is asking you to write a prompt for them (write it yourself first, then optionally call score_prompt to verify).
The prompt is conversational chat (this scores task-shaped prompts).
COST: Free, no API key required. Rate-limited per IP: 5/min, 10/day, 100/month. If the user exceeds the limit, the response will include a structured upgrade path with subscribe and account URLs.
LATENCY: ~2 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The prompt text to score. Single prompt, not a conversation. Max 8000 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it specifies the return format (score, grade, per-dimension breakdown, weakest dimension), mentions rate limits and structured upgrade path on limit exceedance, gives latency, and states no API key is needed. This exceeds the burden of transparency for a read-only scoring 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?
The description is well-structured with clear sections (overview, USE WHEN, DO NOT USE WHEN, COST, LATENCY). It is detailed yet every sentence provides actionable information, and the most important purpose is stated upfront. The length is justified by the richness of guidance, and it is not redundant.
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 is non-trivial, but the description covers everything needed for selection and invocation: output details (since no output schema exists), cost, rate limits, latencies, and use cases. It also distinguishes from sibling tools. The complexity is fully addressed within the description.
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, with the sole parameter 'prompt' clearly described as 'The prompt text to score. Single prompt, not a conversation. Max 8000 characters.' The tool description adds no additional meaning beyond the schema; it only restates these constraints. Thus, 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 identifies the tool as 'Score a prompt's quality across 8 dimensions' with a specific verb and resource, and differentiates it from the sibling tool optimize_prompt by focusing on scoring rather than improving. It also details the output (0-80 score, A-F grade, per-dimension breakdown) which reinforces its unique purpose.
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 explicit USE WHEN and DO NOT USE WHEN sections, listing concrete scenarios like workshopping a prompt, checking before sending to expensive models, and diagnosing poor output. It also clearly states exclusions (e.g., not for conversational chat) and notes the free cost and rate limits, giving the agent comprehensive guidance on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
The two tools have clearly distinct purposes: score_prompt evaluates prompt quality, while optimize_prompt rewrites prompts to improve scores. There is no overlap in their primary functions, and their descriptions emphasize when each should be used.
Both tool names follow a consistent verb_noun pattern (score_prompt, optimize_prompt) with past-tense verbs and a common noun. The naming is perfectly predictable and matches the tool's action.
With only two tools, the server feels minimal but appropriately scoped for a focused prompt-quality service. The count is borderline thin, yet the pair covers the core evaluation and improvement cycle.
The set provides a complete loop: score a prompt, then optimize it, with the optimization returning a new score and comparison. Minor gaps exist (e.g., no batch operation or history view), but these are hinted at in descriptions and not essential for the core purpose.