de en es ja ko ru zh

SentiSift MCP

Name: SentiSift MCP
Author: pickelfintech

by pickelfintech

Overview Schema Source Related Servers Discussions Admin

Python

Remote

SentiSift MCP 服务器

SentiSift 的官方 Model Context Protocol (MCP) 服务器。允许支持 MCP 的 AI 宿主（Claude Desktop、Cursor、VS Code、Continue 等）将 SentiSift 评论审核和智能 API 作为原生工具调用。

此工具的功能

安装后，您的 AI 助手可以：

直接在对话中分析评论：“将这 50 条评论通过 SentiSift 运行，并向我展示机器人评论和情感分布。”
检查您的账户状态：“我的 SentiSift 余额是多少，订阅何时续订？”
获取历史结果：“向我展示昨天关于 example.com/breaking-news 的文章的情感历史。”
自我诊断服务状态：“SentiSift API 是否就绪，还是模型仍在加载中？”

无需编写代码。助手通过 MCP 调用工具并报告结果。

Related MCP server: Semanticscholar Universal MCP Server

公开的工具

工具	描述
`analyze_comments`	提交一批评论及文章 URL，接收机器人/垃圾邮件标记、情感标签、商业内容标记、审核摘要，以及（在 Pro/Enterprise 版中）智能分析 + 交互式影响力评论。
`get_balance`	当前评论余额、等级、功能标志、有效授权、订阅状态、影响力统计数据。
`get_health`	SentiSift API 是否就绪或仍在加载模型。
`get_article_results`	文章 URL 的历史评分评论（Pro/Enterprise 保留完整历史记录；Free/Starter 仅返回缓冲区状态）。

安装

您需要 Python 3.10+ 和 SentiSift API 密钥。可在 sentisift.com/pricing 获取免费密钥（1,000 条评论，无需信用卡）。

推荐：`uvx`（无需安装，始终保持最新）

uv 可以在不进行持久安装的情况下运行已发布的 Python 应用程序。这是无需安装的路径。

# 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-mcp

替代方案：`pip install`

pip install sentisift-mcp
sentisift-mcp   # run manually to verify

宿主配置

每个 AI 宿主都有自己的配置文件。选择您的宿主：

Claude Desktop

编辑配置文件：

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

将 SentiSift 条目添加到 mcpServers：

{
  "mcpServers": {
    "sentisift": {
      "command": "uvx",
      "args": ["sentisift-mcp"],
      "env": {
        "SENTISIFT_API_KEY": "sk_sentisift_your_key_here"
      }
    }
  }
}

重启 Claude Desktop。您应该会在新聊天的左下角看到一个新的工具指示器。尝试：“使用 SentiSift 检查我的余额。”

Cursor

Cursor 通过 Settings → MCP Servers 面板支持 MCP。添加：

Name: sentisift
Command: uvx
Arguments: sentisift-mcp
Environment variables: SENTISIFT_API_KEY=sk_sentisift_your_key_here

或者直接编辑 ~/.cursor/mcp.json，结构与上面的 Claude Desktop 示例相同。

VS Code (使用 MCP 扩展)

编辑您的用户或工作区 settings.json：

{
  "mcp.servers": {
    "sentisift": {
      "command": "uvx",
      "args": ["sentisift-mcp"],
      "env": {
        "SENTISIFT_API_KEY": "sk_sentisift_your_key_here"
      }
    }
  }
}

Continue.dev

在 ~/.continue/config.json 中：

{
  "mcpServers": [
    {
      "name": "sentisift",
      "command": "uvx",
      "args": ["sentisift-mcp"],
      "env": {
        "SENTISIFT_API_KEY": "sk_sentisift_your_key_here"
      }
    }
  ]
}

任何其他支持 MCP 的宿主

该服务器通过 stdio 使用 MCP 通信。将您的宿主指向 uvx sentisift-mcp（如果通过 pip 安装则为 sentisift-mcp），并在其环境中设置 SENTISIFT_API_KEY。

如何与助手对话

配置完成后，可以使用自然语言提示。一些示例：

“检查我的 SentiSift 余额。”

“将这 20 条评论通过 SentiSift 运行，用于 https://example.com/breaking-story 这篇文章。评论如下：” (粘贴它们)

“SentiSift API 现在准备好了吗，还是仍在加载？”

“从 SentiSift 获取 https://example.com/article-42 的已处理评论。”

助手会选择正确的工具，传递正确的参数，并总结结果。如果调用失败，错误响应将包含指向相关文档部分的深度链接，以便助手可以自我纠正。

隐私

服务器发送一个 User-Agent 标头，将其标识为 sentisift-mcp/<version>，以便我们在使用日志中区分 MCP 流量和直接 SDK 流量。没有其他遥测数据。
服务器在您的机器上本地运行。它仅调用 api.sentisift.com。
您的 API 密钥保留在您的机器上（在宿主的环境配置中）。此服务器绝不会将其记录到磁盘。

源码

源码和问题追踪：gitlab.com/pickel-fintech/sentisift-sdks。

链接

许可证

MIT — 参见 LICENSE。此客户端调用的 SentiSift API 服务受 sentisift.com/terms.html 单独管辖；使用 API 需要来自 sentisift.com/pricing 的 API 密钥。

Available Tools

4 tools

analyze_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.

ParametersJSON Schema

Name	Required	Description
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema

Name	Required	Description	Default
`article_url`	Yes	Full URL of the article to retrieve processed results for.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/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 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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Tool Schema Changelog

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

4 tool updatesApr 19, 2026
- First observedanalyze_comments
- First observedget_article_results
- First observedget_balance
- First observedget_health

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

A4.7/5.0

Scored 2026-09-09 18:53 across 4 tools

Disambiguation5/5

Each tool addresses a distinct concern: submission/analysis, balance/account state, service health, and historical results. There is no overlap between analyze_comments and get_article_results because the former is for new submissions while the latter retrieves past processed data. Even get_balance and get_health are clearly separated by purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (analyze_comments, get_balance, get_health, get_article_results). The verbs ('analyze', 'get') and nouns ('comments', 'balance', 'health', 'article_results') are uniformly descriptive and predictable. This makes it easy for an agent to infer functionality from the name alone.

Tool Count5/5

With only 4 tools, the server is tightly scoped to its core functionality: analyzing comments, checking balance, checking health, and retrieving results. This is not too thin for a specialized moderation service; each tool covers a necessary operation without redundancy. The small count reduces ambiguity and helps agents avoid over-selection.

Completeness4/5

The key operations for the stated purpose (sentiment analysis and moderation) are covered: submit and get processed results, fetch historical results, check account status, and verify service readiness. The only minor gap is the lack of a tool to manage or modify existing submissions (e.g., reprocess or delete), but that is not a typical requirement for this domain. Overall, agents can complete primary workflows without dead ends.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

PerigonOAuth
io.github.goperigon
Official Perigon news API: articles, stories, companies, journalists, monitors, and stats.
Search Research & Data Open Data
16
hn-developer-sentiment-mcpOAuth
io.github.digitalgremlin
Deterministic Hacker News developer sentiment, themes & feature requests via MCP. No API key.
Product Management Research & Data Social Media
11
IndieML Substance API
io.github.ezchx
Scores text for substance, depth, and clarity in under 25ms.
AI & Machine Learning
1
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

Related MCP Servers

Sentiment402 MCP Adapter
Finance Search Blockchain
kytona
A
license
Not graded
quality
D
maintenance
Provides 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.
Updated 10 months ago (2025-12-26 18:22 UTC)
MIT
Semanticscholar Universal MCP
Research & Data Search Open Data
universal-mcp
A
license
Not graded
quality
D
maintenance
Provides a standardized interface for interacting with Semanticscholar's tools and services through a unified API.
Updated a year ago (2025-06-14 05:35 UTC)
4
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 6 months ago (2026-04-11 00:58 UTC)
2 npm
MIT
sentiment-analyzer-x402
Br0ski777
A
license
Not graded
quality
C
maintenance
Provides sentiment analysis with emotion detection, confidence scores, and key phrase extraction for single texts or batches up to 20, using pay-per-call via x402 micropayments (USDC on Base L2).
Updated a month ago (2026-09-02 19:57 UTC)
MIT

SentiSift MCP 服务器

此工具的功能

公开的工具

安装

推荐：uvx（无需安装，始终保持最新）

替代方案：pip install

宿主配置

Claude Desktop

Cursor

VS Code (使用 MCP 扩展)

Continue.dev

任何其他支持 MCP 的宿主

如何与助手对话

隐私

源码

链接

许可证

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

推荐：`uvx`（无需安装，始终保持最新）

替代方案：`pip install`