Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Text Classification MCP Server (Model2Vec) classify this article about electric vehicles and AI advancements"
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.
A powerful Model Context Protocol (MCP) server that provides comprehensive text classification tools using fast static embeddings from Model2Vec (Minish Lab).
This server provides 6 essential tools, 2 resources, and 1 prompt template for text classification:
classify_text - Classify single text with confidence scores
batch_classify - Classify multiple texts simultaneously
add_custom_category - Add individual custom categories
batch_add_custom_categories - Add multiple categories at once
list_categories - View all available categories
remove_categories - Remove unwanted categories
categories://list - Access category list programmatically
model://info - Get model and system information
classification_prompt - Ready-to-use classification prompt template
Related MCP server: Intake-Triage
Zero-install: Just uv run — dependencies are declared inline (PEP 723)
Multiple Transports: Supports stdio (local), HTTP/SSE, and Streamable HTTP
Fast Classification: Uses efficient static embeddings from Model2Vec
10 Default Categories: Technology, business, health, sports, entertainment, politics, science, education, travel, food
Custom Categories: Add your own categories with descriptions
Batch Processing: Classify multiple texts at once
Resource Endpoints: Access category lists and model information
Prompt Templates: Built-in prompts for classification tasks
Python 3.10+
uv package manager
No separate install step needed — dependencies are declared inline in the script (PEP 723) and resolved automatically by uv.
uv run text_classifier_server.py# SSE on default port 8000
uv run text_classifier_server.py --http
# SSE on custom port
uv run text_classifier_server.py --http 9000uv run text_classifier_server.py --streamable-httpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"text-classifier": {
"command": "uv",
"args": ["run", "/path/to/text_classifier_server.py"]
}
}
}Start the server with uv run text_classifier_server.py --http, then add:
{
"mcpServers": {
"text-classifier": {
"url": "http://localhost:8000/sse"
}
}
}claude mcp add text-classifier -- uv run /Users/olivier/DEV/mcp-text-classifier/text_classifier_server.pyClassify a single text into predefined categories with confidence scores.
Parameters:
text (string): The text to classify
top_k (int, optional): Number of top categories to return (default: 3)
Returns: JSON with predictions, confidence scores, and category descriptions
Example:
classify_text("Apple announced new AI features", top_k=3)Classify multiple texts simultaneously for efficient processing.
Parameters:
texts (list): List of texts to classify
top_k (int, optional): Number of top categories per text (default: 1)
Returns: JSON with batch classification results
Example:
batch_classify(["Tech news", "Sports update", "Business report"], top_k=2)Add a new custom category for classification.
Parameters:
category_name (string): Name of the new category
description (string): Description to generate the category embedding
Returns: JSON with operation result
Example:
add_custom_category("automotive", "Cars, vehicles, transportation, automotive industry")Add multiple custom categories in a single operation for efficiency.
Parameters:
categories_data (list): List of dictionaries with 'name' and 'description' keys
Returns: JSON with batch operation results
Example:
batch_add_custom_categories([
{"name": "automotive", "description": "Cars, vehicles, transportation"},
{"name": "music", "description": "Music, songs, artists, albums, concerts"}
])List all available categories and their descriptions.
Parameters: None
Returns: JSON with all categories and their descriptions
Remove one or multiple categories from the classification system.
Parameters:
category_names (list): List of category names to remove
Returns: JSON with removal results for each category
Example:
remove_categories(["automotive", "custom_category"])categories://list: Get list of available categories with metadata
model://info: Get information about the loaded Model2Vec model and system status
classification_prompt: Template for text classification tasks with context and instructions
Parameters:
text (string): The text to classify
Returns: Formatted prompt for classification with available categories listed
npx @modelcontextprotocol/inspector uv run text_classifier_server.py# Manual model download
uv run python -c "from model2vec import StaticModel; StaticModel.from_pretrained('minishlab/potion-base-8M')"Model: minishlab/potion-base-8M from Model2Vec
Similarity: Cosine similarity between text and category embeddings
Performance: ~30MB model, fast inference with static embeddings
Protocol: MCP specification 2024-11-05
Transports: stdio, HTTP+SSE, Streamable HTTP
Fork the repository
Create a feature branch
Add tests for new functionality
Submit a pull request
MIT License - see LICENSE file for details.
Model2Vec by Minish Lab for fast static embeddings
Anthropic for the Model Context Protocol specification
FastMCP for the excellent Python MCP framework
Need help? Check the troubleshooting section or open an issue in the repository.
Add a new custom category for classification.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Description of the category to generate its embedding | |
| category_name | Yes | Name of the new category |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks details on side effects, required permissions, or whether the operation is idempotent. It only states the action without disclosing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has an output schema (expected to describe return values), the description omits details about error handling, prerequisites, or when to prefer this over batch alternatives. It is adequate for simple usage but lacks completeness given sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (category_name, description). The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add) and resource (custom category) with a specific purpose (for classification). It differentiates from sibling tools like batch_add_custom_categories (batch) and list_categories or remove_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as batch_add_custom_categories. No context on prerequisites, exclusions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple custom categories for classification in a single operation.
| Name | Required | Description | Default |
|---|---|---|---|
| categories_data | Yes | List of dictionaries with 'name' and 'description' keys Example: [{"name": "music", "description": "Music, songs, artists, albums"}] |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'single operation' without disclosing atomicity, uniqueness constraints, or error handling. Lacks behavioral detail for a batch mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with 10 words, concise and front-loaded. Could potentially add more structure (e.g., mention output) without losing conciseness, but current form is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, output schema exists), description is adequate but leaves unanswered questions about error handling, category validation, and whether operation is atomic. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds little beyond schema. The parameter 'categories_data' already has a detailed description and example. No additional semantic value provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Add' and resource 'multiple custom categories' with context 'for classification in a single operation.' It clearly distinguishes from the sibling 'add_custom_category' which is singular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'add_custom_category' or 'batch_classify.' The description implies batching but does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify multiple texts at once.
| Name | Required | Description | Default |
|---|---|---|---|
| texts | Yes | List of texts to classify | |
| top_k | No | Number of top categories to return for each text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as error handling, rate limits, synchronous/asynchronous behavior, or any constraints on input size. The description only states the core function without any additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no redundant information. It is as concise as possible while conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the batch operation complexity and existence of an output schema, the description is adequate but missing details like maximum batch size, whether processing is synchronous, or how errors are handled for individual texts. The output schema may cover return values, but constraints are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and while the description adds no extra meaning beyond the schema, the schema itself is clear. Baseline 3 is appropriate as the description does not enhance parameter understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Classify multiple texts at once' clearly states the verb (classify) and resource (multiple texts), distinguishing it from the sibling tool 'classify_text' which is for single text classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for batch classification, but does not explicitly state when to use it versus alternatives like 'classify_text' for single texts or 'batch_add_custom_categories'. No when-not or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify text into predefined categories using static embeddings.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to classify | |
| top_k | No | Number of top categories to return (default: 3) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing the full burden on the description. The description mentions 'static embeddings' but does not disclose potential behaviors such as edge cases (e.g., text length limits), performance characteristics, or whether the tool is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. It is appropriately sized with no wasted words, earning a point above the average.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and parameter descriptions are covered, the description is adequate but sparse. It does not mention the output format or any additional context, but the presence of the output schema compensates partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description does not add any additional meaning or constraints beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool classifies text into predefined categories, specifying the verb ('classify') and the resource ('text into predefined categories'). However, it does not distinguish itself from the sibling tool 'batch_classify' which performs a similar function but in batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'batch_classify' or when not to use it. The description lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available categories for classification.
Returns: JSON string with all categories and their descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavior: it is a read operation returning a JSON string. However, it does not clarify if the list includes user-added custom categories or only system defaults, leaving ambiguity about its scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. Every word adds value: 'List all available categories for classification' captures the action and purpose, and the return type is explicitly stated. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is mostly sufficient. However, it lacks clarity on whether custom categories are included, which is relevant given sibling 'add_custom_category'. This minor gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% by default. The description adds no parameter information because none is needed, earning the baseline score of 4 per rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all available categories', making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like 'add_custom_category' and 'classify_text' which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 whether to call it before classification or how it relates to custom categories. The description only states what it does, not the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove one or multiple categories from the classification system.
| Name | Required | Description | Default |
|---|---|---|---|
| category_names | Yes | List of category names to remove |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions 'remove' implying destruction but does not clarify reversibility, impact on classified items, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. However, for a destructive tool, additional context about consequences and usage scenarios would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter is documented in schema). The description adds minimal value beyond noting 'one or multiple', aligning with the array type. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (remove) and object (categories from the classification system). It distinguishes from sibling tools that add or list categories, but does not explicitly call out the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites, side effects, or scenarios to avoid. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_custom_categorybatch_add_custom_categoriesbatch_classifyclassify_textlist_categoriesremove_categoriesEach tool has a distinct purpose: adding categories (single/batch), classifying text (single/batch), listing, and removing categories. No overlap or ambiguity.
All tools use snake_case and follow a consistent verb_noun pattern (e.g., add_custom_category, batch_classify, list_categories). No mixing of styles.
Six tools is well-scoped for a text classification server: category CRUD (add/batch add, list, remove) and classification (single/batch). Neither too few nor too many.
Covers core functionality: category management and classification. Missing an update category tool is a minor gap, but agents can work around it by removing and re-adding.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
Score pages against 11,485 public taxonomy categories by embedding similarity. $0.05/call via MCP.
Run AI models, create deployments, and manage predictions via cloud API
Text Intelligence delivers robust NLP capabilities without the hassle of authentication or
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/baobab-tech/mcp-text-classifier'
If you have feedback or need assistance with the MCP directory API, please join our Discord server