Skip to main content
Glama
deenesjakoruzh
pickelfintech

SentiSift MCP

by pickelfintech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
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 키가 필요합니다. 무료 키(댓글 1,000개, 신용카드 불필요)는 sentisift.com/pricing에서 받을 수 있습니다.

권장: 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

mcpServers에 SentiSift 항목을 추가합니다:

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

Claude Desktop을 다시 시작합니다. 새 채팅의 왼쪽 하단 모서리에 새로운 도구 표시기가 나타나야 합니다. 다음을 시도해 보세요: "Use SentiSift to check my balance."

Cursor

Cursor는 Settings → MCP Servers 패널을 통해 MCP를 지원합니다. 다음을 추가하세요:

  • Name: sentisift

  • Command: uvx

  • Arguments: sentisift-mcp

  • Environment variables: SENTISIFT_API_KEY=sk_sentisift_your_key_here

또는 위 Claude Desktop 예제와 동일한 구조로 ~/.cursor/mcp.json을 직접 편집하세요.

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를 설정하세요.

어시스턴트와 대화하는 방법

구성 후 자연어 프롬프트가 작동합니다. 몇 가지 예시입니다:

"Check my SentiSift balance."

"Run these 20 comments through SentiSift for the article at https://example.com/breaking-story. Here are the comments:" (댓글 붙여넣기)

"Is the SentiSift API ready right now, or is it still loading?"

"Fetch the processed comments for https://example.com/article-42 from SentiSift."

어시스턴트가 올바른 도구를 선택하고, 올바른 인수를 전달하며, 결과를 요약합니다. 호출이 실패하면 오류 응답에 관련 문서 섹션으로 연결되는 딥 링크가 포함되어 어시스턴트가 스스로 수정할 수 있습니다.

개인정보 보호

  • 서버는 사용 로그에서 MCP 트래픽과 직접 SDK 트래픽을 구분할 수 있도록 sentisift-mcp/<version>으로 식별되는 User-Agent 헤더를 보냅니다. 다른 원격 측정은 없습니다.

  • 서버는 로컬 컴퓨터에서 실행됩니다. 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
NameRequiredDescriptionDefault
article_urlYesFull 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.
commentsYesArray 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_textNoFull 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.
titleNoArticle title, for the article profile.
toneNoBrand voice for Influence comments when applicable (e.g. 'professional and measured', 'warm and community-oriented'). Pro/Enterprise tiers only.

Output Schema

ParametersJSON Schema
NameRequiredDescription

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
NameRequiredDescriptionDefault
article_urlYesFull URL of the article to retrieve processed results for.

Output Schema

ParametersJSON Schema
NameRequiredDescription

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
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

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
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

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.

  1. 4 tool updates
    • 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 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

Related MCP Connectors

Related MCP Servers

  • Sentiment402 MCP Adapter

    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.
    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).
    MIT