Skip to main content
Glama

Check length limits

check_length_limits
Read-onlyIdempotent

Use this when the user wants to know whether text fits a limit: an essay minimum or maximum word count, a custom character limit, or platform limits for X/Twitter (280 weighted), Threads, Bluesky, LinkedIn, Instagram captions, SEO title tags, meta descriptions, or SMS segments. Returns pass or fail, how far over or under, and where to cut. Pass the text exactly as written. Does not shorten or rewrite the text and does not post anything.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>"
    },
    "name": "check_length_limits"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesThe exact text to count, copied verbatim from the user without edits (up to 100,000 characters). Example: The quick brown fox jumps over the lazy dog.
languageNoOptional BCP 47 language code, e.g. ja. Improves word splitting for Japanese, Chinese, and Thai; readability scores are only given for English.
max_wordsNoMaximum allowed word count, e.g. 2000.
min_wordsNoMinimum required word count, e.g. 1500.
platformsNoPlatforms to check, e.g. ["x","linkedin"]. x: X/Twitter 280 weighted characters (links 23, emoji and CJK 2). threads: 500. bluesky: 300 graphemes. linkedin: 3,000. instagram: caption 2,200. meta_title: 60. meta_description: 160 (155 safer). sms: 160 GSM-7 or 70 Unicode per message. If nothing is given, x, threads, bluesky, linkedin, and instagram are checked.
exclude_quotesNoLeave out passages inside double quotation marks ("...", curly quotes, guillemets). Example: false.
max_charactersNoA custom character limit (counted as user-perceived characters), e.g. 500.
exclude_headingsNoLeave out headings: Markdown # lines and short title lines directly above a paragraph. Example: true.
exclude_citationsNoLeave out in-text citations: APA (Smith, 2020), (Lee et al., 2019, p. 12), MLA (Smith 23), page refs (p. 4), and numeric [3]. Example: true.
exclude_reference_listNoLeave out everything from a References, Works Cited, or Bibliography heading to the end. Example: true.

Output Schema

NameRequiredDescriptionDefault
kindYes
wordsYes
optionsYes
privacyYes
resultsYes
all_passYes
charactersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes beyond them by stating the return shape (pass or fail, how far over or under, where to cut) and the input contract ("Pass the text exactly as written"). It adds no caveats about weighting subtleties at runtime, but the behavioral surface is well covered.

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 usage condition is front-loaded in the first clause, followed by the supported limit families and then two crisp exclusions. The long platform enumeration is dense but each named platform maps to a distinct checkable limit, so no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and a fully described 10-parameter schema, the description needn't explain return values or the exclude_* options, and it correctly focuses on when to use the tool and its non-goals. The one gap is the absence of any sibling differentiation against count_text.

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?

Schema description coverage is 100%, so parameter semantics are already fully documented; the description's platform list and "pass the text exactly as written" largely restate the schema's own parameter descriptions. The only marginal addition is the note that results indicate where to cut, which is about output rather than parameters.

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?

The description opens with a specific verb+resource framing ("check whether text fits a limit") and enumerates the concrete limit families it handles (essay word counts, custom character limits, platform limits). It never names the sibling count_text, so the agent has no explicit routing signal between counting and limit-checking, which keeps it from a 5.

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?

"Use this when the user wants to know whether text fits a limit" gives a clear entry condition, and the closing sentence carves out what the tool will not do (shorten, rewrite, post), which prevents misuse. It does not explicitly route to or away from count_text, so there is no alternative-tool guidance.

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