Essay Stats MCP

Check a word limit

check_word_limit

Read-only

Checks whether an essay meets a word limit by counting words and reporting remaining or excess words, with options to exclude references and quotes and allow tolerance.

Instructions

Compare an essay against a word limit. Inputs: text, limit (the maximum word count), optional minimum (a lower bound), optional tolerance_percent (how far over the limit is still acceptable, default 0, a common rule is 10), optional exclude_references (cut everything from a heading line such as References, Works Cited or Bibliography to the end) and optional exclude_quotes (leave out block quotes that start with > and text inside double quotes). Returns the counted words, how many are left or over, and what was excluded. Example: "Is this under 2000 words if I leave out the works cited and quotes?.

Input Schema

Name	Required	Description
`text`	Yes
`limit`	Yes	Maximum number of words.
`minimum`	No	Minimum number of words.
`exclude_quotes`	No	Leave out quoted passages. Default false.
`tolerance_percent`	No	Percent over the limit that is still fine. Default 0.
`exclude_references`	No	Leave out the references section. Default false.

Output Schema

Name	Required	Description	Default
`limit`	Yes
`status`	Yes
`minimum`	Yes
`words_over`	Yes
`total_words`	Yes
`counted_words`	Yes
`allowed_maximum`	Yes
`words_remaining`	Yes
`excluded_quote_words`	Yes
`excluded_reference_words`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Oct 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish this as a read-only, closed-world operation. Beyond that, the description adds real behavioral detail: tolerance semantics ('default 0, a common rule is 10'), precise exclusion rules for a References heading and for block/double-quoted text, and a statement of what is returned. It stops short of explaining edge cases like how words are tokenized or whether heading matching is case-insensitive.

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?

The description is front-loaded with the core purpose and then efficiently enumerates inputs and return values. It is somewhat dense in one paragraph and the example sentence has awkward punctuation, but no sentence is wasted.

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?

Given that an output schema exists, the description need not fully specify return values, yet it still summarizes them. With annotations covering safety, six parameters documented at high coverage, and clear exclusion semantics, an agent has enough to invoke the tool correctly.

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

Parameters5/5

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

Schema coverage is already high at 83%, but the description adds meaningful semantics beyond the schema: tolerance_percent includes a practical default and a common 10% rule, exclude_references defines the exact cutoff from a heading line to the end, and exclude_quotes specifies both '>' block quotes and text inside double quotes.

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 gives a specific verb and resource: 'Compare an essay against a word limit.' It clearly separates this tool from sibling counting/diagnostic tools like count_text and readability_scores by emphasizing limit comparison, not raw counting.

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

Usage Guidelines4/5

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

The use case is clear from 'Compare an essay against a word limit' and the example question about staying under 2000 words while excluding works cited and quotes. It does not explicitly say when not to use it or name count_text as the alternative for simple counting.

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

Deploy Server