SentiSift MCP
The SentiSift MCP server enables AI assistants to perform comment moderation, sentiment analysis, and account management through the SentiSift API.
Analyze comments (
analyze_comments): Submit batches of up to 50 (Free) or 2,000 (paid) comments for an article URL to receive sentiment labels (Toxic, Negative, Neutral, Positive, Saccharine), bot/spam detection, commercial-content flags, and moderation summaries. Pro/Enterprise tiers also get crowd-level intelligence (discussion themes, omega ratio, sentiment balance) and AI-generated Influence comments.Check account balance (
get_balance): Retrieve your current comment balance, subscription tier (Free/Starter/Professional/Enterprise), available features, active comment grants with expiry dates, subscription billing state, and Influence generation statistics.Check service health (
get_health): Verify whether the SentiSift API is ready to handle requests or still loading models (typically 10–60 seconds after a cold start).Retrieve historical article results (
get_article_results): Fetch previously processed and scored comments for a given article URL without triggering new processing. Pro/Enterprise tiers return full scored history across all batches; Free/Starter return buffered state only.
SentiSift MCP Server
Official Model Context Protocol (MCP) server for SentiSift. Lets MCP-compatible AI hosts (Claude Desktop, Cursor, VS Code, Continue, and others) call the SentiSift comment-moderation and intelligence API as a native tool.
What this unlocks
Once installed, your AI assistant can:
Analyze comments directly in conversation: "Run these 50 comments through SentiSift and show me the bots and the sentiment distribution."
Check your account state: "What's my SentiSift balance and when does my subscription renew?"
Retrieve historical results: "Show me the sentiment history for yesterday's article on example.com/breaking-news."
Self-diagnose service status: "Is the SentiSift API ready, or are models still loading?"
No code required. The assistant calls the tools through MCP and reports back.
Related MCP server: Semanticscholar Universal MCP Server
Tools exposed
Tool | Description |
| Submit a batch of comments plus an article URL, receive bot/spam flags, sentiment labels, commercial-content flags, moderation summary, and (on Pro/Enterprise) Intelligence + interleaved Influence comments. |
| Current comment balance, tier, feature flags, active grants, subscription state, Influence stats. |
| Whether the SentiSift API is ready or still loading models. |
| Historical scored comments for an article URL (Pro/Enterprise retain full history; Free/Starter return buffer state only). |
Install
You need Python 3.10+ and a SentiSift API key. Free keys (1,000 comments, no credit card) at sentisift.com/pricing.
Recommended: uvx (zero install, always latest)
uv runs published Python apps without persistent install. This is the install-free path.
# One-time: install uv (mac/linux)
curl -LsSf https://astral.sh/uv/install.sh | sh
# Verify it works (Ctrl-C after a few seconds; the server is meant to be
# launched by your AI host, not run in a terminal).
SENTISIFT_API_KEY=sk_sentisift_... uvx sentisift-mcpAlternative: pip install
pip install sentisift-mcp
sentisift-mcp # run manually to verifyHost configuration
Each AI host has its own config file. Pick yours:
Claude Desktop
Edit the config file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Add the SentiSift entry to mcpServers:
{
"mcpServers": {
"sentisift": {
"command": "uvx",
"args": ["sentisift-mcp"],
"env": {
"SENTISIFT_API_KEY": "sk_sentisift_your_key_here"
}
}
}
}Restart Claude Desktop. You should see a new tool indicator in the bottom-left corner of a new chat. Try: "Use SentiSift to check my balance."
Cursor
Cursor supports MCP via the Settings → MCP Servers panel. Add:
Name:
sentisiftCommand:
uvxArguments:
sentisift-mcpEnvironment variables:
SENTISIFT_API_KEY=sk_sentisift_your_key_here
Or edit ~/.cursor/mcp.json directly with the same structure as the Claude Desktop example above.
VS Code (with the MCP extension)
Edit your user or workspace settings.json:
{
"mcp.servers": {
"sentisift": {
"command": "uvx",
"args": ["sentisift-mcp"],
"env": {
"SENTISIFT_API_KEY": "sk_sentisift_your_key_here"
}
}
}
}Continue.dev
In ~/.continue/config.json:
{
"mcpServers": [
{
"name": "sentisift",
"command": "uvx",
"args": ["sentisift-mcp"],
"env": {
"SENTISIFT_API_KEY": "sk_sentisift_your_key_here"
}
}
]
}Any other MCP-compatible host
The server speaks MCP over stdio. Point your host at uvx sentisift-mcp (or sentisift-mcp if installed via pip) and set SENTISIFT_API_KEY in its environment.
How to talk to the assistant
Once configured, natural-language prompts work. Some examples:
"Check my SentiSift balance."
"Run these 20 comments through SentiSift for the article at https://example.com/breaking-story. Here are the comments:" (paste them)
"Is the SentiSift API ready right now, or is it still loading?"
"Fetch the processed comments for https://example.com/article-42 from SentiSift."
The assistant chooses the right tool, passes the right arguments, and summarizes the results. If a call fails, the error response includes a deep link to the relevant docs section so the assistant can self-correct.
Privacy
The server sends a
User-Agentheader identifying it assentisift-mcp/<version>so we can distinguish MCP traffic from direct SDK traffic in our usage logs. No other telemetry.The server runs locally on your machine. It only calls out to
api.sentisift.com.Your API key stays on your machine (in the host's env config). It is never logged to disk by this server.
Source
Source and issue tracker: gitlab.com/pickel-fintech/sentisift-sdks.
Links
Python SDK (this MCP server wraps it)
License
MIT — see LICENSE. The SentiSift API service that this client calls is governed separately by sentisift.com/terms.html; use of the API requires an API key from sentisift.com/pricing.
Available Tools
4 toolsanalyze_commentsA
Submit a batch of comments to SentiSift for moderation and analysis.
Returns a response with status='buffered' (accepted, not yet analyzed, nothing charged) or status='processed' (full analysis returned).
Processed responses include per-comment sentiment labels (Toxic, Negative, Neutral, Positive, Saccharine), bot/spam flags (the response 'comments' array has those removed), composite scores, and on Professional/Enterprise tiers, crowd-level 'intelligence' (discussion_themes, omega_ratio, sentiment_balance) plus interleaved Influence comments marked with is_influence=true.
Comments are buffered per article until a processing threshold is reached, then all accumulated comments are analyzed together. You are billed only when processing occurs.
Batch size caps: 50 comments per call on the Free tier, 2000 on paid tiers.
| Name | Required | Description | Default |
|---|---|---|---|
| article_url | Yes | Full URL of the article the comments belong to (e.g. 'https://example.com/article/42'). Used to group comments and accumulate Intelligence. URLs are normalized server-side. | |
| comments | Yes | Array of comment objects. Each must have 'text' (str), 'author' (str), and 'time' (ISO 8601 str). Optional fields: 'likes' (int), 'dislikes' (int), 'is_reply' (bool). If real author/time are unknown, synthesize stable placeholders (e.g. author='anonymous-1', time='2026-04-18T10:00:00'). | |
| article_text | No | Full article body. STRONGLY RECOMMENDED on the first call for each article (we cache it and use it for contextual analysis and Influence generation). Skip on later calls for the same article URL. | |
| title | No | Article title, for the article profile. | |
| tone | No | Brand voice for Influence comments when applicable (e.g. 'professional and measured', 'warm and community-oriented'). Pro/Enterprise tiers only. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits such as buffering comments per article, batch processing, billing only on processing, and response statuses. Since annotations are absent, the description carries full burden. It covers mutation aspects and pagination/caps but could mention rate limits or idempotency.
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 somewhat lengthy but front-loaded with the core action. It could be more concise by grouping status explanation and tier details. However, each sentence adds necessary 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 the tool's complexity (5 parameters, output schema present, buffering, billing, tier distinctions), the description is complete: it covers input, behavior, response structure, and usage caveats. No significant gaps.
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 baseline is 3. The description adds value by explaining the article_url groups comments, comments array structure with required and optional fields, and recommendations for article_text. It also explains tone and title usage. This justifies a 4.
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 submits comments for moderation and analysis, specifies the two possible response statuses, and details what processed responses include. It distinguishes from siblings by focusing on comment submission vs. retrieving results or checking balance.
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 explains when to use this tool (submitting comments for analysis), provides batch size caps per tier, recommends including article_text on first call, and implies alternative tools (get_article_results) for fetching results. It gives clear context on buffering and billing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_article_resultsA
Fetch already-processed, scored comments for an article URL.
Does NOT trigger new processing and does NOT generate Influence comments (Influence only appears in analyze_comments responses).
Tier behavior:
Free/Starter: returns the buffered state only (processed comments are delivered inline via analyze_comments).
Professional/Enterprise: returns the full scored history accumulated across batches.
Use this when the user asks for historical sentiment of an article already submitted previously, or to check how a discussion has evolved since the last analyze_comments call.
| Name | Required | Description | Default |
|---|---|---|---|
| article_url | Yes | Full URL of the article to retrieve processed results for. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry full burden. It discloses read-only nature (does NOT trigger new processing), tier-dependent result scope, and that Influence scores are absent. However, it does not mention response format, pagination, or data freshness beyond 'buffered state'.
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?
Well structured: one-line summary, then negation, then tier behavior, then usage guidance. Every sentence adds unique value. No redundancy or filler.
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 single parameter with 100% schema coverage, output schema exists (so return values need not be explained), and tool is a simple retrieval, the description is complete. Could mention rate limits or idempotency for extra safety, but not necessary.
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% (single param fully described). Description adds value by clarifying the parameter's role: 'Full URL of the article to retrieve processed results for' is redundant with schema. However, no additional semantic guidance needed as schema already clear.
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?
Verb 'fetch' plus specific resource 'already-processed, scored comments for an article URL'. Contrasts clearly with sibling analyze_comments by explaining what it does NOT do (no new processing, no Influence scores). Distinguishes from get_balance and get_health by focus on comments.
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?
Explicitly states when to use: 'when the user asks for historical sentiment of an article already submitted previously, or to check how a discussion has evolved since the last analyze_comments call.' Also explains when NOT to use: when Influence scores are needed (use analyze_comments). Tier behavior clarifies expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceA
Return the current SentiSift balance, tier, usage counters, and subscription state.
Fields of interest:
comment_balance: remaining comments across all active grants (FIFO consumed)
tier: 'free', 'starter', 'professional', or 'enterprise'
features: which capabilities the current key unlocks (moderate, intelligence, influence)
comment_grants: active allocations with expiry dates
subscription: billing state ('active', 'cancelled', 'past_due') or null for free-tier keys
influence_stats: Influence generation history (if feature enabled)
Call this when the user asks about their balance, upcoming renewals, or whether a feature is available on their tier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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 details the returned fields (balance, tier, features, etc.) and their semantics (e.g., 'FIFO consumed', 'or null for free-tier keys'), which is sufficient for a read-only query. However, it does not mention side effects or edge cases like rate limits or caching, which would be desirable.
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 well-structured with a lead sentence and bulleted details for fields. It is informative but slightly longer than necessary; the field list could be more concise. Overall, it's clear and front-loaded.
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 the tool has zero parameters and an output schema likely defines the structure, the description provides sufficient context for an agent to understand what is returned and when to use it. No gaps are apparent 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 has no parameters, and the description provides rich semantics about what each field in the output means. Since schema coverage is 100% (0 params), the description adds value by explaining the return values beyond schema constraints.
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 a clear verb 'Return' and specifies the resource 'SentiSift balance, tier, usage counters, and subscription state'. It also lists sibling tools like 'analyze_comments' and 'get_health', and this tool's purpose is distinct from them, as it focuses on account details.
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 explicitly states when to call this tool: 'when the user asks about their balance, upcoming renewals, or whether a feature is available on their tier'. This provides clear context and implies when not to use it (e.g., for other queries), though no alternative tools are named for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_healthA
Check if the SentiSift service is ready to handle requests.
Returns {'status': 'ready'} when models are loaded and requests will be served normally, or {'status': 'loading', 'progress': 0.4} during a cold start (usually 10-60 seconds after a restart).
Call this before a large batch analysis if response latency matters, or when diagnosing 'service appears slow' complaints. The analyze_comments tool handles transient loading states automatically with retries, so this is typically informational.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values for both ready and loading states, including progress field. No annotations provided, so description carries full burden. Could mention potential rate limits or side effects, but as a read-only health check, this is sufficient.
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?
Concise, front-loaded with purpose, followed by a line explaining return format, and a final line with usage guidelines. Every sentence adds value.
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 zero parameters, no annotations, and an output schema existing, the description fully covers the tool's behavior and use cases. No gaps.
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?
No parameters in schema; description adds no param info needed. Score baseline 4 for zero params, plus no extra detail required, so 5 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?
Clearly states the tool checks if the SentiSift service is ready. Differentiates from siblings like analyze_comments, which handles transient states automatically.
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?
Explicitly describes when to use: before large batch analysis if latency matters, or for diagnosing slowness. Notes analyze_comments handles loading automatically, so this is informational.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool targets a distinct operation: submitting comments for analysis, fetching historical results, checking balance/tier, and verifying service health. No overlaps or ambiguity.
All tools follow a consistent verb_noun pattern (analyze_comments, get_article_results, get_balance, get_health), using snake_case and clear verbs.
Four tools for a sentiment analysis API server is well-scoped: core analysis, results retrieval, account info, and health check. No superfluous or missing tools.
Covers the main workflow (submit, retrieve results, check balance, health). Minor gap: no tool to list or manage articles explicitly, but get_article_results covers retrieval by URL.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Deterministic Hacker News developer sentiment, themes & feature requests via MCP. No API key.
Toxicity, sentiment, NER, PII detection, and language identification tools
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
Search and analyze global news coverage and US TV transcripts via the GDELT Project APIs.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides access to Sentiment402 market sentiment data for global markets, crypto, TradFi, and specific assets, with built-in support for x402 micropayment protocol when API responses require payment.MIT
- AlicenseNot gradedqualityDmaintenanceProvides a standardized interface for interacting with Semanticscholar's tools and services through a unified API.4MIT
- AlicenseNot gradedqualityDmaintenanceAlgorithmic text and NLP analysis server providing sentiment, readability, keyword extraction, language detection, stats, and more via REST and MCP.2MIT
- AlicenseAqualityCmaintenanceProvides tools to search, retrieve, and explore over 200M academic papers, authors, citations, and full-text snippets via the Semantic Scholar API.1681MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pickelfintech/sentisift-sdks'
If you have feedback or need assistance with the MCP directory API, please join our Discord server