Skip to main content
Glama

Count words and characters

count_text
Read-onlyIdempotent

Use this when the user asks how long a text is, for example "how many words is this", "character count for this tweet", "will this fit in one SMS", "how long does this take to read". Input tips: pass text exactly as written, up to 20,000 characters (about 3,500 words); do not trim or fix it. Returns: characters, characters without spaces, graphemes (user-perceived characters), words, sentences, paragraphs, lines, UTF-8 bytes, SMS encoding, units and segments, reading minutes, and Flesch reading ease and grade (English only, null otherwise), with the rule used for each count. Not for: counting text inside a file, PDF or spreadsheet the tool cannot see (paste the text instead), or counting tokens for a model. Errors: a text over the limit is refused; split it and add the counts. The text is not stored.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe text to count, exactly as the user wrote it (at most 20000 characters, about 3,500 words).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
smsYesHow a carrier would send the text as SMS.
linesYesLines separated by a line break.
rulesYesThe rule behind each count, to quote when the user asks what counts as a word or a character.
wordsYesRuns of non-whitespace; a hyphenated word or a number is 1 word.
graphemesYesCharacters as a reader sees them; an emoji with a skin tone is 1.
sentencesYesSentences, split with English sentence rules.
charactersYesUnicode code points; an emoji counts as 1.
paragraphsYesBlocks of text separated by blank lines.
utf8_bytesYesSize of the text in UTF-8 bytes.
reading_minutesYesSilent reading time in minutes at 238 words a minute, one decimal.
flesch_reading_easeYesFlesch Reading Ease, higher is easier (60 to 70 is plain English); null for non-English text or text with no sentence.
characters_no_spacesYesCode points that are not whitespace.
flesch_kincaid_gradeYesFlesch-Kincaid US school grade level; null for non-English text or text with no sentence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed21 schema fields changed
    • addedOutput schema / properties / characters / description
      Added value: +"Unicode code points; an emoji counts as 1."
    • addedOutput schema / properties / characters_no_spaces / description
      Added value: +"Code points that are not whitespace."
    • addedOutput schema / properties / flesch_kincaid_grade / description
      Added value: +"Flesch-Kincaid US school grade level; null for non-English text or text with no sentence."
    • addedOutput schema / properties / flesch_reading_ease / description
      Added value: +"Flesch Reading Ease, higher is easier (60 to 70 is plain English); null for non-English text or text with no sentence."
    • addedOutput schema / properties / graphemes / description
      Added value: +"Characters as a reader sees them; an emoji with a skin tone is 1."
    • addedOutput schema / properties / lines / description
      Added value: +"Lines separated by a line break."
    • addedOutput schema / properties / paragraphs / description
      Added value: +"Blocks of text separated by blank lines."
    • addedOutput schema / properties / reading_minutes / description
      Added value: +"Silent reading time in minutes at 238 words a minute, one decimal."
    • addedOutput schema / properties / rules / description
      Added value: +"The rule behind each count, to quote when the user asks what counts as a word or a character."
    • addedOutput schema / properties / rules / properties
      Added value: +{
      +  "characters": {
      +    "description": "How characters are counted.",
      +    "type": "string"
      +  },
      +  "characters_no_spaces": {
      +    "description": "How characters without spaces are counted.",
      +    "type": "string"
      +  },
      +  "flesch": {
      +    "description": "How the Flesch scores are counted.",
      +    "type": "string"
      +  },
      +  "graphemes": {
      +    "description": "How graphemes are counted.",
      +    "type": "string"
      +  },
      +  "lines": {
      +    "description": "How lines are counted.",
      +    "type": "string"
      +  },
      +  "paragraphs": {
      +    "description": "How paragraphs are counted.",
      +    "type": "string"
      +  },
      +  "reading_minutes": {
      +    "description": "How reading minutes are counted.",
      +    "type": "string"
      +  },
      +  "sentences": {
      +    "description": "How sentences are counted.",
      +    "type": "string"
      +  },
      +  "sms": {
      +    "description": "How SMS units and segments are counted.",
      +    "type": "string"
      +  },
      +  "utf8_bytes": {
      +    "description": "How UTF-8 bytes are counted.",
      +    "type": "string"
      +  },
      +  "words": {
      +    "description": "How words are counted.",
      +    "type": "string"
      +  }
      +}
    • addedOutput schema / properties / rules / required
      Added value: +[
      +  "characters",
      +  "characters_no_spaces",
      +  "graphemes",
      +  "words",
      +  "sentences",
      +  "paragraphs",
      +  "lines",
      +  "utf8_bytes",
      +  "sms",
      +  "reading_minutes",
      +  "flesch"
      +]
    • addedOutput schema / properties / sentences / description
      Added value: +"Sentences, split with English sentence rules."
    • addedOutput schema / properties / sms / description
      Added value: +"How a carrier would send the text as SMS."
    • addedOutput schema / properties / sms / properties / encoding / description
      Added value: +"GSM-7 for the basic alphabet, UCS-2 when any other character is present."
    • addedOutput schema / properties / sms / properties / encoding / enum
      Added value: +[
      +  "GSM-7",
      +  "UCS-2"
      +]
    • addedOutput schema / properties / sms / properties / segments / description
      Added value: +"Messages the text is split into: 1 when it fits in 160 GSM-7 or 70 UCS-2 units."
    • addedOutput schema / properties / sms / properties / units / description
      Added value: +"Encoding units used; a GSM extension character such as the euro sign counts 2."
    • addedOutput schema / properties / sms / required
      Added value: +[
      +  "encoding",
      +  "units",
      +  "segments"
      +]
    • addedOutput schema / properties / utf8_bytes / description
      Added value: +"Size of the text in UTF-8 bytes."
    • addedOutput schema / properties / words / description
      Added value: +"Runs of non-whitespace; a hyphenated word or a number is 1 word."
    • addedOutput schema / required
      Added value: +[
      +  "characters",
      +  "characters_no_spaces",
      +  "graphemes",
      +  "words",
      +  "sentences",
      +  "paragraphs",
      +  "lines",
      +  "utf8_bytes",
      +  "sms",
      +  "reading_minutes",
      +  "flesch_reading_ease",
      +  "flesch_kincaid_grade",
      +  "rules"
      +]
  2. Changed1 schema field changed
    • removedOutput schema / properties / note_from_openkrill
      Removed value: -{
      -  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
      -  "type": "string"
      -}
  3. Changed1 schema field changed
    • addedOutput schema / properties / note_from_openkrill
      Added value: +{
      +  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds behavior they cannot express: the 20,000-character ceiling (about 3,500 words) with a refusal on overflow and a stated remedy, plus the fact that the input text is not stored. That is exactly the extra operational context the annotations lack.

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?

Front-loads the trigger conditions, then input tips, returns, exclusions, and errors in a scannable order with no filler sentences. The one weak spot is the enumerated Returns list, which restates fields already covered by the output schema.

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 one-parameter read-only tool this is fully specified: trigger cases, input limits, failure behavior and remedy, exclusions, and data-handling are all covered, and return values are delegated to the existing output schema as intended.

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

Parameters4/5

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

Schema description coverage is 100%, so the single parameter is already documented. The description still adds practical guidance (pass text exactly as written, don't trim or fix it, size the input against the ~3,500-word equivalent), which is mildly beyond the schema but largely overlapping.

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?

States a specific verb+resource (counting words/characters in text) and anchors it in real user phrasings like "how many words is this" and "will this fit in one SMS". It is unmistakably distinct from every sibling tool (feedback, calendar, CSV, translate).

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?

Explicitly says when to use it (user asks how long a text is) and when not to: counting text inside a file/PDF/spreadsheet, or counting model tokens. It even supplies the workaround (paste the text, split oversized input and add the counts).

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.