Skip to main content
Glama

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 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

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 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Resources