Skip to main content
Glama
enesjakozh
kukapay

crypto-sentiment-mcp

by kukapay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Crypto Sentiment MCP 서버

AI 에이전트에게 암호화폐 감정 분석을 제공하는 MCP 서버로, Santiment의 집계된 소셜 미디어 및 뉴스 데이터를 활용하여 시장 분위기를 추적하고 새로운 추세를 감지합니다.

GitHub 라이센스파이썬 버전상태

특징

  • 감정 분석 : 특정 암호화폐에 대한 감정 균형(긍정적 대 부정적)을 검색합니다.

  • 소셜 볼륨 추적 : 전체 소셜 미디어 언급량을 모니터링하고 상당한 변화(급증 또는 감소)를 감지합니다.

  • 사회적 지배력 : 암호화폐 미디어에서 자산이 차지하는 토론의 점유율을 측정합니다.

  • 인기 단어 : 암호화폐 토론에서 가장 인기 있는 트렌드 용어를 알아보세요.

Related MCP server: etf-flow-mcp

도구

도구 이름

설명

매개변수

get_sentiment_balance

특정 기간 동안 자산에 대한 평균적인 감정 균형을 파악합니다.

asset: str , days: int = 7

get_social_volume

자산에 대한 소셜 미디어 언급의 총 수를 가져옵니다.

asset: str , days: int = 7

alert_social_shift

이전 평균과 비교했을 때 소셜 볼륨의 상당한 급증이나 감소를 감지합니다.

asset: str , threshold: float = 50.0 , days: int = 7

get_trending_words

특정 기간 동안 점수별로 순위를 매겨 암호화폐 토론에서 가장 인기 있는 단어를 검색합니다.

days: int = 7 , top_n: int = 5

get_social_dominance

자산이 주도하는 암호화폐 미디어 토론의 비율을 측정합니다.

asset: str , days: int = 7

필수 조건

  • 파이썬 : 3.10 이상

  • Santiment API 키 : Santiment 에서 무료 또는 유료 키를 받으세요.

설치

  1. 저장소 복제 :

    지엑스피1

  2. 클라이언트 구성 :

    {
  "mcpServers": {
    "crypto-sentiment-mcp": {
      "command": "uv",
      "args": ["--directory", "path/to/crypto-sentiment-mcp", "run", "main.py"],
      "env": {
        "SANTIMENT_API_KEY": "your_api_key_here"
      }
    }
  }
}

예시

다음은 MCP 호환 클라이언트를 통해 서버와 상호 작용할 때 자연어 입력과 해당 출력의 예입니다.

  • 입력 : "지난주 비트코인에 대한 감정적 균형은 어땠나요?"

    • 출력 : "지난 7일간 비트코인의 감정 균형은 12.5입니다."

  • 입력 : "지난 5일 동안 소셜 미디어에서 이더리움이 몇 번 언급되었나요?"

    • 출력 : "지난 5일간 이더리움의 소셜 볼륨은 8,432개 언급되었습니다."

  • 입력 : "최근 비트코인의 소셜 볼륨에 30% 한계치로 큰 변화가 있었는지 알려주세요."

    • 출력 : "비트코인의 소셜 볼륨은 지난 24시간 동안 75.0%나 급증하여 평균 1,000에서 1,750으로 증가했습니다."

  • 입력 : "지난 3일간 암호화폐에서 가장 인기 있었던 단어 3가지는 무엇입니까?"

    • 출력 : "지난 3일간 가장 인기 있었던 단어 3개: 'halving', 'bullrun', 'defi'."

  • 입력 : "이번 주 소셜 미디어 토론에서 이더리움은 얼마나 지배적일까?"

    • 출력 : "지난 7일간 이더리움의 사회적 지배력은 18.7%입니다."

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

Available Tools

5 tools
alert_social_shiftA

Detect significant shifts (spikes or drops) in social volume (social_volume_total) for a given asset.

Parameters:

  • asset (str): The cryptocurrency slug (e.g., "bitcoin", "ethereum"). Required.

  • threshold (float): Minimum percentage change (absolute value) to trigger an alert, defaults to 50.0 (i.e., 50%).

  • days (int): Number of days to analyze for baseline volume, defaults to 7.

Usage:

  • Call this tool to check if the latest social volume has significantly spiked or dropped compared to the previous average.

Returns:

  • A string indicating if a shift occurred (e.g., "Bitcoin's social volume spiked by 75.0% in the last 24 hours" or "Bitcoin's social volume dropped by 60.0% in the last 24 hours").

ParametersJSON Schema
NameRequiredDescriptionDefault
assetYes
thresholdNo
daysNo

TDQS

A4.1/5.0
Behavior3/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 describes what the tool does (detects shifts based on percentage change) and the return format (a string indicating shift occurrence). However, it doesn't mention important behavioral aspects like rate limits, authentication requirements, data freshness, or error conditions that would help an agent use it correctly.

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?

The description is well-structured with clear sections (purpose, parameters, usage, returns) and every sentence earns its place. It's appropriately sized at 4 sentences plus parameter explanations, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, 0% schema description coverage, and no output schema, the description does a decent job explaining purpose, parameters, and returns. However, for a tool that performs analysis and returns alerts, it lacks details about the algorithm (e.g., how baseline is calculated), time windows for comparison, and potential limitations that would help an agent use it effectively.

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?

The schema description coverage is 0%, so the description must compensate. It provides clear semantic explanations for all three parameters: 'asset' is explained as 'cryptocurrency slug', 'threshold' as 'minimum percentage change', and 'days' as 'number of days to analyze for baseline volume'. Default values are also documented. This adds substantial value beyond the bare schema.

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's purpose with specific verbs ('detect significant shifts'), resource ('social volume for a given asset'), and scope ('spikes or drops in social_volume_total'). It distinguishes from sibling tools like get_social_volume (which presumably returns raw volume) by focusing on change detection and alerts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Usage' section explicitly states when to use this tool ('to check if the latest social volume has significantly spiked or dropped compared to the previous average'). However, it doesn't provide guidance on when NOT to use it or mention alternatives among the sibling tools (e.g., when to use get_social_volume instead).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sentiment_balanceB

Retrieve the sentiment balance (sentiment_balance_total) for a given asset.

Parameters:

  • asset (str): The cryptocurrency slug (e.g., "bitcoin", "ethereum"). Required.

  • days (int): Number of days to calculate the average sentiment balance, defaults to 7.

Usage:

  • Use this tool to get the average sentiment balance (positive minus negative sentiment) over a period.

Returns:

  • A string with the average sentiment balance (e.g., "Bitcoin's sentiment balance over the past 7 days is 12.5").

ParametersJSON Schema
NameRequiredDescriptionDefault
assetYes
daysNo

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data and describes the return format, but lacks details on permissions, rate limits, error handling, or whether it's a read-only operation. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is well-structured and appropriately sized, with clear sections for purpose, parameters, usage, and returns. Every sentence adds value without redundancy, and it's front-loaded with the core function. There's no wasted text, making it efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 parameters with 0% schema coverage and no output schema, the description does a decent job by explaining parameters and the return format. However, it lacks details on behavioral aspects like authentication or limits, and doesn't fully address sibling tool differentiation. For a simple retrieval tool, it's adequate but has clear gaps in completeness.

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 description coverage is 0%, so the description must compensate. It adds meaningful semantics: it explains that 'asset' is a 'cryptocurrency slug' with examples, and 'days' is for 'calculating the average sentiment balance' with a default. This clarifies beyond the bare schema, though it could provide more context on valid asset values or day ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Retrieve the sentiment balance (sentiment_balance_total) for a given asset.' It specifies the verb ('retrieve') and resource ('sentiment balance'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like get_social_dominance or get_social_volume, which likely retrieve different social metrics for assets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'Usage' section that says 'Use this tool to get the average sentiment balance (positive minus negative sentiment) over a period,' which implies when to use it. However, it doesn't provide explicit guidance on when to choose this tool over alternatives (e.g., get_social_dominance for dominance metrics) or any exclusions, leaving usage context somewhat implied rather than fully articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_social_dominanceA

Retrieve the social dominance (social_dominance_total) for a given asset. Social Dominance shows the share of the discussions in crypto media that is referring to a particular asset or phrase.

Parameters:

  • asset (str): The cryptocurrency slug (e.g., "bitcoin", "ethereum"). Required.

  • days (int): Number of days to calculate average social dominance, defaults to 7.

Usage:

  • Call this tool to get the percentage of social media discussion dominated by the asset.

Returns:

  • A string with the average social dominance (e.g., "Bitcoin's social dominance over the past 7 days is 25.3%").

ParametersJSON Schema
NameRequiredDescriptionDefault
assetYes
daysNo

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves data (read-only behavior) and explains what social dominance represents. However, it doesn't mention potential limitations like rate limits, authentication requirements, data freshness, or error conditions. The description adds some behavioral context but leaves gaps for a data retrieval tool.

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 clear sections (description, parameters, usage, returns) and front-loaded the core purpose. Most sentences earn their place, though the 'Usage' section slightly repeats the purpose. It's appropriately sized for a 2-parameter tool without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 parameters with 0% schema coverage and no output schema, the description does a decent job explaining parameters and return format. However, for a data retrieval tool with no annotations, it lacks details on error handling, data sources, or example responses beyond a single string format. The completeness is adequate but has clear 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 description coverage is 0%, so the description must compensate. It clearly explains both parameters: 'asset' as a cryptocurrency slug with examples, and 'days' as the number of days for calculating average social dominance with a default value. This adds meaningful semantics beyond the bare schema. However, it doesn't specify constraints like valid slug formats or day ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Retrieve the social dominance (social_dominance_total) for a given asset' and explains what social dominance measures. It uses specific verbs ('retrieve', 'shows') and identifies the resource ('asset'), but doesn't explicitly differentiate from sibling tools like get_social_volume or get_sentiment_balance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'Usage' section stating 'Call this tool to get the percentage of social media discussion dominated by the asset,' which provides implied context about when to use it. However, it doesn't explicitly mention when NOT to use it or suggest alternatives among the sibling tools (e.g., when to choose get_social_volume instead).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_social_volumeA

Retrieve the total social volume (social_volume_total) for a given asset. It calculates the total number of social data text documents that contain the given search term at least once. Examples of documents are telegram messages and reddit posts.

Parameters:

  • asset (str): The cryptocurrency slug (e.g., "bitcoin", "ethereum"). Required.

  • days (int): Number of days to sum the social volume, defaults to 7.

Usage:

  • Call this tool to get the total number of social media mentions for an asset over a period.

Returns:

  • A string with the total social volume (e.g., "Bitcoin's social volume over the past 7 days is 15,000 mentions").

ParametersJSON Schema
NameRequiredDescriptionDefault
assetYes
daysNo

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the tool performs a calculation based on social data documents (telegram messages, reddit posts) and mentions the default value for days. However, it doesn't cover important behavioral aspects like rate limits, authentication requirements, data freshness, or error conditions that would be crucial for an agent.

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?

The description is well-structured with clear sections (purpose, parameters, usage, returns) and every sentence earns its place. The front-loaded purpose statement is specific, and subsequent sections efficiently provide necessary details without redundancy.

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 the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is mostly complete. It covers purpose, parameters, usage, and return format. However, without annotations or output schema, it could benefit from more behavioral context about limitations or edge cases to be fully comprehensive.

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?

With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains that 'asset' is a cryptocurrency slug with examples ('bitcoin', 'ethereum'), clarifies it's required, and explains that 'days' specifies the time period to sum with a default of 7. This adds substantial meaning beyond the bare schema.

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 specific action ('retrieve the total social volume'), the resource ('for a given asset'), and the calculation method ('calculates the total number of social data text documents that contain the given search term at least once'). It distinguishes from siblings by focusing on total volume rather than sentiment, dominance, or trending words.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Usage' section explicitly states when to call this tool ('to get the total number of social media mentions for an asset over a period'), providing clear context. However, it doesn't mention when NOT to use it or explicitly name alternatives like get_sentiment_balance or get_social_dominance for different analytical needs.

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. 5 tool updates
    • First observedalert_social_shift
    • First observedget_sentiment_balance
    • First observedget_social_dominance
    • First observedget_social_volume
    • First observedget_trending_words
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

A3.9/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap. alert_social_shift detects volume changes, get_sentiment_balance measures sentiment polarity, get_social_dominance calculates discussion share, get_social_volume counts mentions, and get_trending_words identifies popular terms. The descriptions reinforce these unique functions, eliminating any confusion.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern with four tools using 'get_' and one using 'alert_'. While 'alert_' deviates slightly, it still maintains readability and logical grouping. All names are snake_case and descriptive, making the set predictable and easy to navigate.

Tool Count5/5

With 5 tools, this server is well-scoped for crypto sentiment analysis. Each tool serves a specific, non-redundant function within the domain, covering key metrics like volume, sentiment, dominance, and trends. The count is neither too sparse nor bloated, fitting the purpose efficiently.

Completeness4/5

The toolset covers core aspects of crypto sentiment analysis: volume tracking, sentiment measurement, dominance calculation, and trend identification. A minor gap exists in lacking tools for historical data comparison or predictive analytics, but agents can work around this by combining existing tools for basic workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches