How do I use Text Processor MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Text Processor MCP detect language of 'Bonjour le monde'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Text Processor MCP

by maki198906

Overview Schema Source Related Servers Discussions Admin

Python

Text Processor MCP

A text processing toolkit with 9 tools for text analysis, available as:

MCP server (server.py) — for any MCP client (Claude, VS Code, etc.)
Gradio web UI (app.py) — browser interface with tabs for each tool
Pi plugin (text-processor-plugin/) — skills + extension for Pi coding agent

🚀 Quick Start

# Install dependencies
uv sync

# Run the MCP server (stdio)
uv run python server.py

# Run the Gradio web UI
uv run python app.py

Related MCP server: Ukraine War MCP

🛠 Tools

#	Tool	Description	Method
1	Analyze Text	Word/sentence/character statistics	Pure Python
2	Extract Keywords	Most frequent words (with stopword filtering)	`Counter`
3	Check Reading Level	Flesch-Kincaid grade level estimate	Pure Python
4	Reverse Text	Reverse a string	Pure Python
5	Analyze Sentiment	Polarity (-1 to +1) and subjectivity	`TextBlob`
6	Detect Language	Identify language of text	`langid`
7	Summarize Text	Extractive summarization (word frequency scoring)	Pure Python
8	Check Spelling	Find misspelled words + suggest corrections	`TextBlob`
9	Readability Tips	Suggestions for clearer writing (sentence length, passive voice, repetition)	Pure Python

🧪 Examples

All examples use the same input text about English articles.

Input text:

The articles in English are the definite article the and the indefinite article a (which takes the alternate form an when followed by a vowel sound). They are the two most common determiners. The definite article is the default determiner when the speaker believes that the listener knows the identity of a common noun's referent (because it is obvious, because it is common knowledge, or because it was mentioned in the same sentence or an earlier sentence). The indefinite article is the default determiner for other singular, countable, common nouns, while no determiner is the default for other common nouns. Other determiners are used to add semantic information such as amount (many, a few), proximity (this, those), or possession (my, the government's).

1. Analyze Text

Input: analyze_text(text)

Output:

{
  "total_characters": 760,
  "characters_without_spaces": 639,
  "total_words": 122,
  "total_sentences": 5,
  "average_word_length": 5.24,
  "average_sentence_length": 24.4,
  "unique_words": 74
}

2. Extract Keywords

Input: extract_keywords(text, count=8)

Output:

{
  "keywords": [
    {"word": "common", "frequency": 5},
    {"word": "article", "frequency": 4},
    {"word": "default", "frequency": 3},
    {"word": "determiner", "frequency": 3},
    {"word": "other", "frequency": 3},
    {"word": "definite", "frequency": 2},
    {"word": "indefinite", "frequency": 2}
  ]
}

3. Check Reading Level

Input: check_reading_level(text)

Output:

{
  "grade_level": 17.6,
  "reading_level": "College/Academic"
}

4. Reverse Text

Input: reverse_text("Hello World")

Output:

dlroW olleH

5. Analyze Sentiment

Input: analyze_sentiment(text)

Output:

{
  "polarity": -0.034,
  "subjectivity": 0.388,
  "sentiment_label": "Neutral",
  "subjectivity_label": "Objective"
}

Polarity: -1 (negative) to +1 (positive). Subjectivity: 0 (objective) to 1 (subjective).

6. Detect Language

Input: detect_language(text)

Output:

{
  "language_code": "en",
  "language_name": "English",
  "confidence": -1851.642
}

More examples:

Input	Result
`"Артикли в английском языке..."`	`ru` (Russian)
`"Les articles en anglais..."`	`fr` (French)
`"Die Artikel im Englischen..."`	`de` (German)

7. Summarize Text

Input: summarize_text(text, max_sentences=3)

Output:

{
  "summary": "They are the two most common determiners. The indefinite article is the default determiner for other singular, countable, common nouns, while no determiner is the default for other common nouns.",
  "original_sentences": 5,
  "summary_sentences": 2,
  "compression_ratio": "40%"
}

8. Check Spelling

Input: check_spelling("The definte article is the most common determiner in english.")

Output:

{
  "misspelled_count": 2,
  "misspelled_words": [
    {
      "original": "definte",
      "suggestions": ["definite", "define"],
      "best_correction": "definite",
      "confidence": 0.857
    },
    {
      "original": "determiner",
      "suggestions": ["determined", "determine"],
      "best_correction": "determined",
      "confidence": 0.577
    }
  ],
  "corrected_text": "The definite article is the most common determined in english."
}

9. Readability Tips

Input: readability_tips(text)

Output:

{
  "overall_assessment": "Found 3 area(s) for improvement (severity: moderate).",
  "statistics": {
    "sentence_count": 5,
    "word_count": 122,
    "avg_sentence_length": 24.4,
    "avg_word_length": 5.0
  },
  "tips": [
    {
      "issue": "Sentences are slightly long",
      "detail": "Average sentence length is 24.4 words.",
      "suggestion": "Consider shortening some sentences to improve clarity."
    },
    {
      "issue": "Too many long words",
      "detail": "Found 4 words longer than 10 characters.",
      "suggestion": "Use simpler, shorter alternatives for complex terms."
    },
    {
      "issue": "Word repetition",
      "detail": "Some words are overused: \"common\" (5x), \"article\" (4x).",
      "suggestion": "Use synonyms or pronouns to vary your vocabulary."
    }
  ]
}

📦 Dependencies

mcp[cli] — Model Context Protocol framework
gradio — Web UI framework
textblob — NLP (sentiment, spelling)
langid — Language detection (97 languages)

🏗 Project Structure

text-processor-mcp/
├── .mcp.json                 # MCP client config (stdio)
├── .gitignore                # Git ignore rules
├── server.py                 # MCP server with all 9 tools
├── app.py                    # Gradio web UI (8 tabs)
├── pyproject.toml            # Project config & dependencies
├── uv.lock                   # Locked dependency versions
├── text-processor-plugin/    # Pi package (skills + extension)
│   ├── package.json
│   ├── README.md
│   ├── extensions/
│   │   └── text-processor.ts
│   └── skills/
│       ├── analyze-text/SKILL.md
│       ├── extract-keywords/SKILL.md
│       ├── check-reading-level/SKILL.md
│       ├── reverse-text/SKILL.md
│       ├── analyze-sentiment/SKILL.md
│       ├── detect-language/SKILL.md
│       ├── summarize-text/SKILL.md
│       ├── check-spelling/SKILL.md
│       └── readability-tips/SKILL.md
└── README.md

🔌 MCP Integration

Two ways to connect: stdio (standalone MCP server) or SSE (via Gradio, which also serves the web UI).

Choose the approach that fits your client.

⚡ Pi (the coding agent)

Pi doesn't support MCP natively. Two options:

Option 1 — Use the Pi plugin (recommended):

Install the plugin with skills + extension:

pi install ./text-processor-plugin

Then install the MCP adapter for direct tool access:

pi install npm:pi-mcp-adapter

The project already ships with .mcp.json pre-configured for stdio.

Option 2 — Global config via ~/.config/pi/config.json:

{
  "mcpServers": {
    "text-processor": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/text-processor-mcp", "python", "server.py"]
    }
  }
}

🖥 Claude Desktop

In claude_desktop_config.json:

{
  "mcpServers": {
    "text-processor": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/text-processor-mcp", "python", "server.py"]
    }
  }
}

💻 VS Code (Cline / Continue / etc.)

These clients read .mcp.json from the project root automatically:

{
  "servers": {
    "text-processor": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "--directory", "/path/to/text-processor-mcp", "python", "server.py"]
    }
  }
}

Note: Replace /path/to/text-processor-mcp with the absolute path to the project.

📁 Project-level `.mcp.json` (already included)

The project ships with .mcp.json pre-configured for stdio (standalone MCP server). Edit it to switch to SSE or adjust paths as needed.

🖥 Web UI

Run uv run python app.py to open the Gradio interface with tabs for each tool. The Gradio app also exposes MCP tools via SSE at http://127.0.0.1:7860/gradio_api/mcp/.

Available Tools

9 tools

analyze_sentimentB

Analyze the sentiment (polarity and subjectivity) of text.

Args: text: The input text to analyze

Returns: JSON string with sentiment analysis results

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the return format (JSON string) and does not disclose read-only nature, side effects, or any limitations. This is minimal for a tool with zero annotation coverage.

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 description is short and front-loaded with the purpose, followed by a clear Args and Returns structure. No wasted words or redundant information.

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?

For a simple single-parameter tool with an output schema, the description covers the essential behavior. It doesn't explain edge cases, but the simplicity makes it sufficient. The mention of polarity and subjectivity clarifies the scope.

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?

The description explains that the text parameter is the input text to analyze, which adds slight meaning beyond the schema's bare type. However, with 0% schema description coverage, more detail (e.g., length limits or encoding) could be provided, though it is adequate for a single simple parameter.

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 clearly states the verb 'analyze' and the resource 'sentiment of text', explicitly specifying polarity and subjectivity. This distinguishes it from siblings like extract_keywords or detect_language, making its purpose unambiguous.

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 guidance is provided on when to use this tool versus alternatives such as analyze_text or summarize_text. The description does not mention any conditions, exclusions, or preferences, leaving the agent to infer usage context.

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

analyze_textC

Analyze text and return statistics.

Args: text: The input text to analyze

Returns: JSON string with analysis results

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden. It discloses that results come as a JSON string, but does not say what statistics are produced, whether the text is processed whole or tokenized, or any edge-case behavior (empty text, long input). For a text-processing tool with zero annotation coverage, this is a meaningful gap.

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 docstring is compact with clean Args/Returns sections and front-loads the purpose in the first sentence. The Args section does repeat the schema, but the Returns clause adds useful information about the JSON string output. No wasted sentences.

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

Completeness3/5

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

An output schema exists, so return values need not be spelled out, and there is only one self-evident parameter. However, the core ambiguity of what 'statistics' means remains unaddressed, and with no usage guidance, the description is only minimally complete for such a simple tool.

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 0%, so the description must compensate. It adds 'The input text to analyze' for the text parameter, but this essentially restates what the schema title 'Text' already implies. The parameter is self-evident, so the added value is minimal yet adequate for a single obvious parameter.

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

Purpose3/5

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

The description states a verb ('analyze') and a resource ('text') and mentions 'statistics' as the output, but 'statistics' is vague and undefined. With siblings like analyze_sentiment, summarize_text, and extract_keywords all analyzing text, this description does not specify which statistics (word count, character count, frequency) are computed, so it does not distinguish itself from its siblings.

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 guidance is given on when to use this tool versus the eight siblings. The description does not state exclusions, alternatives, or context for choosing it over analyze_sentiment or check_reading_level. An agent has no way to route between these tools from the description alone.

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

check_reading_levelC

Estimate reading difficulty level.

Args: text: The input text

Returns: JSON string with reading level estimate

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of disclosing behavior. It vaguely states a JSON string is returned but does not describe whether the input is modified, whether network calls are made, or what fields the estimate contains. The term 'estimate' implies read-only, but this is not explicit.

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 appropriately short and front-loaded with the main purpose. The Args/Returns sections are standard and not overly verbose, though they add little beyond the first sentence.

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

Completeness3/5

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

The tool is simple with one parameter and an output schema, so the description covers the basic purpose, input, and return type. However, it lacks important context such as the metric used (e.g., grade level, Flesch-Kincaid), return structure, and relationship to readability_tips.

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

Parameters1/5

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

The only parameter, text, is described as 'The input text', which merely restates the parameter name. The schema already indicates it is a string, so the description adds no additional semantic value such as expected length, language, encoding, or constraints.

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 clearly states the tool estimates reading difficulty level, using the verb 'Estimate' and specifying the resource as reading difficulty. However, it does not differentiate itself from the sibling readability_tips tool or specify the exact output metric.

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 guidance is provided on when to use this tool versus alternatives like readability_tips or analyze_text. There is no mention of preferred contexts, exclusions, or complementary tools.

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

check_spellingB

Identify misspelled words and suggest corrections.

Args: text: The text to check for spelling errors

Returns: JSON string with misspelled words, corrections, and corrected text

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior1/5

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

The description gives no information about side effects, permissions, read-only vs. destructive behavior, rate limits, or any other behavioral aspects. No annotations are provided to supplement this.

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 description is concise and well-structured: it starts with a single-sentence purpose, followed by an Args section and a Returns section. No unnecessary words or repetition.

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 the simplicity of the tool, the description is complete. It specifies what input is expected, what the tool does, and what the output format is. There are no ambiguous points or missing essential details for a basic spelling-check function.

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?

The description adds significant meaning to the sole parameter, explaining that 'text' is 'the text to check for spelling errors'. Since the schema provides no description for the parameter, this fills the gap completely. It also describes the output structure.

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 clearly states the tool's function with specific verbs ('Identify', 'suggest') and a clear resource ('misspelled words'). However, it does not explicitly distinguish itself from sibling text-processing tools, though the name itself strongly implies a unique purpose.

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

Usage Guidelines1/5

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

No guidance is provided about when to use this tool versus the sibling tools (e.g., analyze_text, extract_keywords). The description lacks any context for when spelling checking would be preferred over other text analysis operations.

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

detect_languageA

Detect the language of the input text.

Args: text: The text to identify language for

Returns: JSON string with detected language code and name

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

The description discloses that the tool returns a JSON string with a language code and name, which is some behavioral transparency. However, it does not explicitly state whether the operation is read-only or has side effects, though the nature of detection implies safety. With no annotations provided, the description could have been more explicit about its non-destructive behavior.

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 description is extremely concise and well-structured. It states the purpose, defines the argument, and describes the return value in a compact format with no unnecessary words or redundancy, following a clear 'Purpose / Args / Returns' structure.

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?

The description is complete for a simple language detection tool. It explains the input and the output format. However, it omits details like the exact JSON structure or a list of supported languages, which might be useful but are not critical for basic use. The lack of an output schema makes this slightly less complete than ideal.

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?

The description compensates for the lack of schema parameter descriptions by defining the single parameter: 'text: The text to identify language for.' This fully clarifies the expected input, making the parameter semantics clear and unambiguous.

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 clearly states the tool's purpose: 'Detect the language of the input text.' It uses a specific verb ('Detect') and identifies the resource ('language of the input text'), distinguishing it from sibling text analysis tools like analysis or summarization.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions for use or contrast with other text processing tools, leaving the agent to infer applicability solely from the name and simple description.

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

extract_keywordsA

Extract keywords (most common words) from text.

Args: text: The input text count: Number of keywords to return (default 5)

Returns: JSON string with keywords and frequencies

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`count`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Mentions output as JSON string with keywords and frequencies, but lacks details on edge cases (e.g., stop words, case sensitivity, handling of non-words).

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?

Extremely concise—three short lines covering purpose, parameters, and return type. No superfluous information.

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?

Provides sufficient context for a simple text analysis tool: purpose, parameters, and return format are all mentioned. Slight gap on the exact structure of the JSON output, but not critical for basic usage.

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?

Both parameters (text, count) are described in the schema and the description, achieving 100% schema coverage. Description adds minimal meaning beyond schema—'most common words' clarifies text processing, but count semantics are surface-level.

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?

Clearly states it extracts keywords (most common words) from text, which is a specific verb+resource. Distinct from sibling tools like sentiment analysis or summarization.

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

Usage Guidelines3/5

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

Usage is implied rather than explicitly stated—if the user needs keywords, this tool is the obvious choice. No explicit comparison to sibling tools or when-not-to-use guidance.

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

readability_tipsC

Analyze text and suggest improvements for clarity.

Args: text: The text to analyze

Returns: JSON string with readability issues and suggestions

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are present, so the description must carry the transparency burden. It indicates the tool returns a JSON string but does not explicitly state whether it is read-only, whether input text is stored, or whether there are any side effects.

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 description is concise and well-structured with Args and Returns sections. Every sentence contributes useful information without redundancy or fluff.

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

Completeness3/5

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

For a simple single-parameter tool, the description covers the basic function and return format. However, it lacks usage context, parameter constraints, and any relation to sibling tools, leaving some gaps for an agent deciding when to invoke it.

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?

The schema provides no description for the 'text' parameter, and the description only says 'The text to analyze,' which adds minimal meaning beyond the parameter name. Details such as accepted format, length limits, or language constraints are missing.

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 clearly states that the tool analyzes text and suggests improvements for clarity, giving a specific verb and resource. It is distinguishable from generic analysis tools, though it could more explicitly mention readability as the core focus.

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

Usage Guidelines1/5

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

There is no guidance about when to use this tool versus alternatives such as check_reading_level or analyze_text. No conditions, exclusions, or preferred contexts are provided.

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

reverse_textB

Reverse a string.

Args: text: The input text

Returns: The reversed text

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description alone must convey side effects and safety. It states only the transformation and gives no explicit statement that the operation is pure, read-only, or free of side effects. Although reversing a string is inherently non-destructive, the lack of explicit disclosure lowers the score.

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 description is exceptionally concise, using only the essential words to convey the operation and parameter. There is no fluff, redundancy, or unnecessary detail, making it easy to parse and understand at a glance.

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?

Given the simplicity of the tool, the description is adequate: it states the function, the input, and the output. It does not discuss edge cases or performance, but for a straightforward string utility this is unlikely to cause confusion. The context provided by the sibling tools (all text-analysis functions) reinforces that this is a basic utility, so no additional context is required.

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?

The parameter 'text' is described as 'The input text', which adds minimal value beyond the schema's type and name. The description does not clarify expectations (e.g., whether the input must be non-empty, how whitespace is handled). However, since the parameter's meaning is essentially self-evident and the schema fully specifies the type, a baseline score of 3 is appropriate.

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 clearly states the action ('Reverse') and the object ('a string'), and identifies the input parameter 'text'. It is immediately obvious what the tool does, though it lacks any nuance about the exact scope (e.g., whether it reverses Unicode graphemes or code units).

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 guidance is provided on when to use this tool versus alternatives. While the sibling tools are all text-analysis functions, none of them perform string reversal, so the absence of comparative guidance is less critical, but the description still gives no indication of limitations or edge cases (e.g., empty strings, multi-byte characters).

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

summarize_textA

Create a short extractive summary of the text.

Args: text: The text to summarize max_sentences: Maximum number of sentences in the summary (default 3)

Returns: JSON string with summary and metadata

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`max_sentences`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Since no annotations are provided, the description carries the full burden. It mentions 'extractive' which implies the output is drawn from the input, but it does not explicitly state that the input is not modified or that it's read-only. It also does not mention any side effects or permissions needed. The behavior is somewhat transparent but not fully explicit.

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 moderately concise with a clear structure: a one-line summary followed by Args and Returns sections. It avoids unnecessary detail, but the inclusion of the full Args and Returns blocks is somewhat standard and not overly verbose.

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?

Given the simple operation with two parameters, the description adequately covers the input and output format. It mentions the return is a JSON string with summary and metadata, which is sufficient for an agent to understand the output, even though the exact metadata structure is not specified. The presence of an output schema (if any) would complement this.

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?

Although the schema has no descriptions, the tool description includes an 'Args' section that fully explains each parameter: 'text' is the text to summarize, and 'max_sentences' is the maximum number of sentences with a default of 3. This provides clear meaning beyond the schema.

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 clearly states the tool's function: 'Create a short extractive summary of the text.' It specifies the resource (text) and the action (summarize extractively). It distinguishes from siblings by focusing on summarization rather than analysis or keyword extraction.

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?

The description does not provide guidance on when to use this tool compared to alternatives. It lacks explicit conditions or scenarios where summarization is preferred over other text processing tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.1.0Sep 7, 2026
- First observedanalyze_sentiment
- First observedanalyze_text
- First observedcheck_reading_level
- First observedcheck_spelling
- First observeddetect_language
- First observedextract_keywords
- First observedreadability_tips
- First observedreverse_text
- First observedsummarize_text

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-09-07 08:15 across 9 tools

Disambiguation4/5

Most tools have distinct purposes, but analyze_text is generic and could potentially overlap with other tools like check_reading_level or readability_tips. However, descriptions clarify outputs, so confusion is minimal.

Naming Consistency4/5

The naming pattern is mostly verb_noun (e.g., extract_keywords, check_spelling), but readability_tips deviates by using a noun phrase instead of a verb. This is a minor inconsistency.

Tool Count5/5

With 9 tools, the count is well within the typical 3-15 range and each tool serves a clear text processing function without being excessive.

Completeness4/5

The set covers a broad range of text processing tasks including analysis, keywords, sentiment, language detection, summarization, and readability. It lacks some possible features like translation or text generation, but for the stated purpose it is quite comprehensive.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

NLP Tools - Sentiment, NER, Toxicity & Language Detection A
io.github.fasuizu-br
Toxicity, sentiment, NER, PII detection, and language identification tools
Language Translation Research & Data Text Summarization
2
seo-mcp A
com.metricspot
Six tools for SEO and AI-readability audits. 91 checks, 11 score modules.
Marketing Web Scraping
62
Brainiall NLP A
com.brainiall
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
AI & Machine Learning Text Summarization Language Translation
221
revieworacle B
io.tooloracle
ReviewOracle - 8 review intel tools: sentiment, themes, competitors, response drafts.
Customer Support Marketing Product Management
82

Related MCP Servers

FastMCP Document Analyzer
Documentation Access Search Text Summarization
Tathagat017
F
license
Not graded
quality
D
maintenance
A comprehensive document analysis server that performs sentiment analysis, keyword extraction, readability scoring, and text statistics while providing document management capabilities including storage, search, and organization.
Updated a year ago (2025-07-05 03:23 UTC)
-
Ukraine War MCP
Search Text Summarization Research & Data
mcmurtrya
A
license
Not graded
quality
Not graded
maintenance
Provides text analysis tools including TF-IDF document search and text profiling (sentiment, readability, keywords) for analyzing text corpora through structured MCP interfaces.
Updated 9 months ago (2025-12-04 22:37 UTC)
BSD 3-Clause
text-stats-ai-mcp
AI & Machine Learning Developer Tools
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
Provides text analysis tools including word counting, reading time estimation, keyword density analysis, and sentiment scoring.
Updated 11 days ago (2026-09-04 12:44 UTC)
7 npm
41 PyPI
MIT
text-analysis-api
AI & Machine Learning Text Summarization Research & Data
lazymac2x
A
license
Not graded
quality
D
maintenance
Algorithmic text and NLP analysis server providing sentiment, readability, keyword extraction, language detection, stats, and more via REST and MCP.
Updated 5 months ago (2026-04-11 00:58 UTC)
2 npm
MIT

Text Processor MCP

🚀 Quick Start

🛠 Tools

🧪 Examples

1. Analyze Text

2. Extract Keywords

3. Check Reading Level

4. Reverse Text

5. Analyze Sentiment

6. Detect Language

7. Summarize Text

8. Check Spelling

9. Readability Tips

📦 Dependencies

🏗 Project Structure

🔌 MCP Integration

⚡ Pi (the coding agent)

🖥 Claude Desktop

💻 VS Code (Cline / Continue / etc.)

📁 Project-level .mcp.json (already included)

🖥 Web UI

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

📁 Project-level `.mcp.json` (already included)