readability-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| readability_score_textA | Compute Flesch Reading Ease and Flesch-Kincaid Grade Level for a block of English text. Use this to check how easy your own draft output (a reply, a document, documentation) will be for a reader to understand before sending it -- useful for agents that want to self-check plain-language quality, or for comparing readability across different drafts. Args:
Returns: For JSON format: { "supported": boolean, // false if the text contains non-Latin script (Flesch formulas assume English) "fleschReadingEase": number|null, // 0-100, higher = easier; null if unsupported or no words found "fleschKincaidGradeLevel": number|null, // approximate US school grade level "gradeLevelLabel": string|null, // human description, e.g. "standard (around 8th-9th grade)" "sentenceCount": number, "wordCount": number, "syllableCount": number, "avgWordsPerSentence": number, "avgSyllablesPerWord": number } Examples:
Error Handling:
|
| readability_simplify_textA | Rewrite English text in plainer language: breaks overly long sentences at natural clause boundaries and swaps common bureaucratic vocabulary ("utilize" -> "use", "prior to" -> "before") for plainer equivalents. Also reports the Flesch Reading Ease score before and after, so you can confirm the rewrite actually helped. Use this before sending a reply, document, or notice to a user who may benefit from plainer language -- including as a self-check step for an agent's own drafted output. Args:
Returns: For JSON format: { "supported": boolean, // false if text contains non-Latin script (English-only feature); simplifiedText equals the input unchanged in that case "simplifiedText": string, "changeCount": number, // total words/phrases substituted "changes": [ { "start": number, "end": number, "original": string, "simplified": string } ], // offsets index into simplifiedText "truncated": boolean, // true if changeCount exceeds 50 (only the first 50 are listed) "fleschReadingEaseBefore": number|null, "fleschReadingEaseAfter": number|null } Examples:
Error Handling:
|
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 2 tools
The two tools have clearly distinct purposes: one measures readability metrics, the other rewrites text to simplify it. There is no overlap or ambiguity in choosing between them.
Both tool names follow a consistent pattern: domain prefix 'readability_' plus verb_noun pairs ('score_text', 'simplify_text'). The naming is uniform and predictable.
Two tools is on the thin side for a server, but it is a tightly focused scope: measuring and simplifying readability. It feels slightly minimal but each tool earns its place.
For the stated purpose of assessing and improving plain-language readability, the server covers both key operations: evaluating a text's readability and rewriting it into plainer language. No obvious critical gap exists.