Click on "Deploy 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., "@varta-mcp classify this message: "Claim your prize now!""
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.
Spam classification MCP server for AI agents — built from real Telegram moderation data.
Live at: https://mcp.getvarta.com/sse
Get a free API key: https://isitaspam.com/developers
Tool | Description |
| Classify a message as SPAM / SUSPICIOUS / SAFE. Returns verdict, confidence (0–1), category, risk signals, red flags, and plain-language recommendation. |
| Daily spam classification statistics from isitaspam.com. |
| Five most recent public spam catches with links to full analysis. |
Related MCP server: Straight Connect
claude mcp add varta \
--transport sse \
https://mcp.getvarta.com/sse \
--header "Authorization: Bearer varta_YOUR_KEY"Get a free key (50 checks/day) at https://isitaspam.com/developers — instant, no credit card.
The hosted server above is the easiest path. If you'd rather run the server as a local process — or your MCP client only speaks stdio — use the bundled stdio entry point. Same three tools, no dependencies, Node 18+.
git clone https://github.com/DarynaFor/mcp-varta.git
cd mcp-varta
API_KEY=varta_YOUR_KEY node src/stdio.jsOr wire it into a client config:
{
"mcpServers": {
"varta": {
"command": "node",
"args": ["/path/to/mcp-varta/src/stdio.js"],
"env": { "API_KEY": "varta_YOUR_KEY" }
}
}
}initialize and tools/list work without a valid key, so registries and clients
can introspect the server before you have one.
curl -s -X POST https://mcp.getvarta.com/messages \
-H "Content-Type: application/json" \
-H "Authorization: Bearer varta_YOUR_KEY" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "check_spam_text",
"arguments": {
"text": "Earn $5000/week from home! Click: bit.ly/abc123"
}
}
}'Response:
**Verdict: SPAM** (97% confidence)
**Category:** financial scam
**Why flagged:**
- Unrealistic income claim ($5000/week)
- Shortened URL hides real destination
**Recommended action:** Delete message and ban sender.
**Source:** isitaspam.com/check/financial_scam-earn-5000-week-a1b2c3d4The classifier runs 7-layer detection:
Fast pre-classifier (keyword + pattern signals)
Multi-LLM consensus (GPT + Claude + Gemini) for ambiguous cases
Vector similarity against 1,100+ verified scam patterns
URL safety check (Google Safe Browsing + PhishTank)
Crypto scam signal detection
Language detection (33 languages)
Stylometric analysis (urgency density, caps ratio, mixed-script patterns)
Data comes from 51 live Telegram groups protecting 29,000+ members via Varta — a Telegram anti-spam SaaS.
Endpoint | Transport |
| SSE (Claude Code |
| HTTP ( |
| Info / health check |
Pass your API key as a Bearer token:
Authorization: Bearer varta_YOUR_KEYFree tier: 50 checks/day
Paid tiers: 2,000/day ($19/mo) · 10,000/day ($49/mo) — see https://isitaspam.com/developers#pricing
Rate limiting is applied by isitaspam.com. On 429, the error body includes reset_at and upgrade_url.
Code | Meaning |
| Bearer token not recognised |
| Daily or burst limit hit |
| Message exceeds 5,000 chars |
If you prefer REST over MCP, the same keys work on isitaspam.com/api/check via X-API-Key header. Full OpenAPI 3.1 spec: https://isitaspam.com/openapi.yaml
MIT
Classify a text message as SPAM, SUSPICIOUS, or SAFE using multi-LLM consensus (GPT + Claude + Gemini) and vector similarity against 1,100+ verified scam patterns. Returns verdict, confidence, category, risk signals, red flags, and plain-language recommendation. Built from real Telegram moderation data.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Message text to classify. Max 5,000 characters. | |
| locale | No | ISO 639-1 language hint (e.g. 'uk', 'ru', 'de'). Auto-detected if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the use of GPT, Claude, and Gemini, vector similarity, and the output fields (verdict, confidence, category, risk signals, red flags, recommendation). Missing are potential limitations or failure modes, but the core behavior is well described.
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 three short sentences, each earning its place: the classification action, the return values, and the data provenance. There is no unnecessary detail or repetition.
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 moderate complexity and the absence of an output schema, the description compensates by listing the return fields. It covers purpose, method, and outputs but omits edge cases like error handling or accuracy caveats, which are minor for this use case.
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?
The input schema already provides thorough descriptions for both 'text' (max 5000 chars) and 'locale' (ISO 639-1, auto-detected). The tool description adds no extra parameter-specific meaning, so the schema does the heavy lifting, warranting the baseline score.
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 starts with 'Classify a text message as SPAM, SUSPICIOUS, or SAFE' – a specific verb, resource, and outcome. The mention of multi-LLM consensus and vector similarity against scam patterns further differentiates it from sibling tools like get_spam_stats and get_spam_examples.
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 clearly implies the tool is for classifying text messages, distinguishing it from sibling tools that provide stats or examples. However, it does not explicitly state when not to use this tool or directly reference alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the 5 most recent public spam/scam examples caught by the isitaspam.com classifier. Each result includes verdict, category, and a link to the full analysis.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It provides useful behavioral context: returns exactly 5 most recent public examples and includes verdict, category, and a link to full analysis. It does not discuss auth, rate limits, or pagination, but for a zero-parameter read tool this is adequate.
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, front-loaded with the action verb 'Get', and contains no filler or redundant information.
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 0 parameters and no output schema, the description is complete for its scope. It communicates the count (5), scope (most recent public), subject (spam/scam examples), and return content (verdict, category, link).
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?
The tool has no parameters, so the schema defines nothing. The baseline for zero parameters is 4, and the description adds value by describing the output fields, which is more than enough for a parameterless tool.
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 retrieves the 5 most recent public spam/scam examples from the isitaspam.com classifier. This distinguishes it from sibling tools like check_spam_text (checks a text) and get_spam_stats (gets statistics) by focusing on example records.
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?
There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for fetching example records, but it does not mention check_spam_text or get_spam_stats, or specify any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily spam classification statistics from isitaspam.com — total checks today, how many were classified as SPAM, how many as SUSPICIOUS. Cached 60 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses a key behavioral trait: 'Cached 60 seconds,' indicating potential staleness. It also enumerates exactly which statistics are returned (total checks, SPAM, SUSPICIOUS), providing useful context beyond what an empty schema would imply.
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?
Two sentences with immediate verb-first structure. The source, key metrics, and caching behavior are all stated without any filler or redundancy.
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?
For a zero-parameter tool with no output schema, the description covers the data source, exact statistics, time scope ('today'), and cache lifetime. This is fully sufficient for an agent to know what to expect.
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?
The tool has zero parameters and 100% schema coverage (trivial). Baseline 4 applies because the description need not explain parameters that don't exist.
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 opens with 'Get daily spam classification statistics' – a specific verb and resource. It distinguishes itself from siblings (check_spam_text, get_spam_examples) by focusing on aggregate metrics rather than text analysis or example retrieval.
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 context implies use when one needs general spam stats, but it does not explicitly state when to use it over alternatives or when not to use it. Sibling tools are listed separately but not referenced in the description.
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.
v1.0.0check_spam_textget_spam_examplesget_spam_statsScored across 3 tools
Each tool has a clearly distinct purpose: check_spam_text classifies a single message, get_spam_stats provides aggregate counts, and get_spam_examples shows recent samples. There is no overlap in functionality or confusion about which tool to use for a given task.
All tool names follow a consistent verb_noun pattern: check_spam_text, get_spam_stats, get_spam_examples. The verbs (check, get) and nouns (text, stats, examples) are clear and predictable.
With three tools, the server is on the lower end of the ideal range, but it is well-scoped for a narrow spam-classification utility. Each tool serves a distinct need, and the count feels appropriate rather than sparse.
The core functionality (classifying a text) is covered, along with supporting statistical and example retrieval. Minor gaps exist (e.g., batch processing or category filtering), but these are not essential for the stated purpose and can be worked around.
Email safety MCP server. Detects phishing, prompt injection, CEO fraud for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP Server for an Agent Task Marketplace
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
