Skip to main content
Glama

x402-readability-score

Readability Score: Returns word, sentence and syllable counts plus Flesch score, grade and reading level 🆓 5 free trial calls per signed wallet

Input Schema

NameRequiredDescriptionDefault
textNo
inputNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / input / description
      Removed value: -"Input to process"
    • removedInput schema / properties / text / description
      Removed value: -"Text to process"
  2. Changed1 schema field changed
    • addedInput schema / properties / text
      Added value: +{
      +  "description": "Text to process",
      +  "type": "string"
      +}
  3. First observed

TDQS

B3.2/5.0
Behavior3/5

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

No annotations, so the description carries the burden. It does disclose a genuine behavioral fact an agent would otherwise miss — 5 free trial calls per signed wallet, implying a paid x402 endpoint requiring a signed wallet. However, it does not state the read-only nature explicitly, rate limits after the trial, or error/response behavior.

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

Conciseness4/5

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

Single front-loaded sentence covering purpose and outputs, with the pricing note appended. Efficient, though the emoji/trial-call marketing line is not strictly tool-selection information.

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?

For a simple stateless text-metric tool with no annotations or output schema, the description enumerates the returned metrics well enough to call it. The only gap is the text/input ambiguity, which is a schema problem more than a description one.

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

Parameters2/5

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

Two string parameters (text, input) with 0% schema description coverage and no parameter guidance in the description. The description never says which field to supply, and the presence of two near-synonymous undocumented inputs is a real ambiguity an agent could trip on.

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

Purpose4/5

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

States specifically what the tool returns: word, sentence and syllable counts plus Flesch score, grade and reading level. That output list distinguishes it from generic siblings like x402-word-count or x402-text-stats, though it never explicitly names what it is not.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no routing to close siblings such as x402-reading-level, x402-syllable-count, or x402-avg-sentence-length. The only extra sentence is a promotional trial-call line, not usage context.

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.

Resources