Skip to main content
Glama

pqs-mcp-server

by io.github.OnChainAIIntel

score_prompt

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYesThe prompt text to score. Single prompt, not a conversation. Max 8000 characters.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: it notes the tool is free, rate-limited (5/min, 10/day, 100/month), and takes ~2 seconds latency. It also explains the structured upgrade path response on rate-limit exceedance, providing critical operational context an agent needs.

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?

The description is well-organized with clear sections (USE WHEN, DO NOT USE WHEN, COST, LATENCY) and front-loaded with the primary purpose. Every sentence adds value, and the structure makes key information easy to parse for an agent.

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

Completeness5/5

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

Despite having only one parameter and no output schema, the description explains the return value (0-80 score, A-F grade, per-dimension breakdown, weakest dimension), operation cost, and usage boundaries. This is sufficient for an agent to correctly invoke the tool and interpret results.

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

Parameters3/5

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

The input schema already covers the single parameter 'prompt' with a clear description (single prompt, max 8000 chars). The tool description adds context about task-shaped prompts in the DO NOT USE section, but does not significantly elaborate beyond the schema. Given 100% schema coverage, a baseline of 3 is appropriate.

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?

The description clearly states the tool's function: scoring a prompt's quality across 8 dimensions before sending to an expensive model. It specifies the verb 'score' and the resource 'prompt', and lists the exact output dimensions (clarity, specificity, etc.), distinguishing it from the sibling 'optimize_prompt' which would alter the prompt rather than just evaluate it.

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 description provides explicit USE WHEN and DO NOT USE WHEN sections, listing concrete scenarios such as workshopping a prompt, pre-sending long prompts, or diagnosing poor output. It also clarifies when not to use it (e.g., when the user asks to write a prompt), implicitly guiding the agent to alternative actions like writing first.

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

All pqs-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0
Disambiguation5/5

The two tools have completely distinct purposes: one scores a prompt's quality, the other optimizes it. The descriptions clearly specify when to use each, so an agent is unlikely to confuse them.

Naming Consistency5/5

Both tools follow the verb_noun pattern (score_prompt, optimize_prompt), making the naming predictable and consistent across the set.

Tool Count4/5

With only 2 tools, the set is slightly below the typical 3-15 range, but it is well-scoped for the narrow domain of prompt scoring and optimization. Each tool serves a clear and complementary purpose.

Completeness5/5

The server covers the complete workflow: score a prompt to identify weaknesses, then optimize it to improve the score. There are no obvious missing operations or dead ends in this domain.

Resources