RSS3 MCP Server
OfficialRSS3용 MCP 서버
RSS3 API를 통합한 MCP 서버 구현입니다. Open Web을 매력적으로 쿼리하세요.
특징
https://docs.rss3.io/guide/developer/api 에 있는 내용입니다.
예를 들어,
분산형 체인 및 플랫폼에 대한 데이터 쿼리
소셜 미디어 플랫폼에서 데이터를 쿼리합니다.
RSS3 네트워크에서 데이터 쿼리(스테이킹, 노드 등에 대한 정보)
AI 인텔 쿼리.
...
예시
비탈릭은 최근에 무엇을 했나요?
최근의 AI 정보에 대해 말해주세요.
ID 2048인 RSS3 칩 보여주세요
스테이킹하기 가장 좋은 RSS3 노드는 무엇입니까?
Related MCP server: MCP-RSS-Crawler
용법
Claude Desktop과 함께 사용
claude_desktop_config.json 에 다음을 추가하세요:
지엑스피1
커서를 사용한 사용
설정 -> 커서 설정 열기
"MCP"를 클릭하세요
다음을 사용하여 새로운 MCP 서버를 추가합니다.
{
"mcpServers": {
"rss3": {
"command": "npx",
"args": [
"mcp-server-rss3"
]
}
}
}ChatWise와 함께 사용
설정 -> 도구를 엽니다.
다음 명령으로 새 도구를 추가합니다.
npx mcp-server-rss3Available Tools
1 toolAPI-get-input-schemaA
Get the input schema for a given API. We should always use this tool to get the input schema for a given API before calling the API.
| Name | Required | Description | Default |
|---|---|---|---|
| toolName | No | The name of the tool to get the input schema for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as read-only nature, authentication needs, or side effects. While the action implies no side effects, the description fails to explicitly state any behavioral constraints beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundant information. Purpose is front-loaded in the first sentence. Every word 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 the tool's simplicity (1 parameter, no output schema, no annotations), the description adequately covers its purpose and usage. However, it does not describe the output format or return value, which would be useful for an agent invoking this tool.
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% for the single parameter 'toolName', with a clear description. The tool description adds no additional meaning beyond what the schema already provides, meeting baseline expectations but not exceeding them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the input schema for a given API and emphasizes using it before calling the API. Verb and resource are specific. No sibling tools to differentiate, but purpose is unambiguous.
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 'always use this tool to get the input schema... before calling the API.' Provides clear when-to-use guidance. No alternatives or exclusions needed due to absence of siblings.
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. Dates show when Glama detected each change.
45 tool updates
v0.1.0- Removed
API-batchGetAccountsActivities - Removed
API-batchGetFederatedAccountsActivities - Removed
API-get_ai_intels_api_v1_ai_intel_get - Removed
API-get_tweets_by_handle_api_v1_tweets__handle__get - Removed
API-getAccountActivities - Removed
API-getActivityById - Removed
API-getAIDataByPath - Removed
API-getAllChips - Removed
API-getAllEpochs - Removed
API-getAllNodes - Removed
API-getBridgingTransactionByHash - Removed
API-getBridgingTransactions - Removed
API-getChipById - Removed
API-getChipImageById - Removed
API-getDSLTotalRequests - Removed
API-getEpochAPYSnapshots - Removed
API-getEpochById - Removed
API-getEpochsAverageAPY - Removed
API-getEpochTransactionByHash - Removed
API-getFederatedAccountActivities - Removed
API-getFederatedActivityById - Removed
API-getFederatedNetworkActivities - Removed
API-getFederatedPlatformActivities - Removed
API-getNetworkActivities - Removed
API-getNetworkConfig - Removed
API-getNodeAssets - Removed
API-getNodeAvatarByAddress - Removed
API-getNodeByAddress - Removed
API-getNodeCountSnapshots - Removed
API-getNodeEventsByAddress - Removed
API-getNodeOperationProfitByAddress - Removed
API-getNodeOperationProfitSnapshots - Removed
API-getNodeRewardsByEpoch - Removed
API-getPlatformActivities - Removed
API-getRSS3TokenTotalSupply - Removed
API-getRSSActivityByPath - Removed
API-getStakerCountSnapshots - Removed
API-getStakerProfit - Removed
API-getStakerProfitSnapshots - Removed
API-getStakersAndNodes - Removed
API-getStakerStats - Removed
API-getStakingTransactionByHash - Removed
API-getStakingTransactions - Removed
API-getTokenTVL - Removed
API-health_check_api_v1_health_get
46 tool updates
- First observed
API-batchGetAccountsActivities - First observed
API-batchGetFederatedAccountsActivities - First observed
API-get_ai_intels_api_v1_ai_intel_get - First observed
API-get_tweets_by_handle_api_v1_tweets__handle__get - First observed
API-get-input-schema - First observed
API-getAccountActivities - First observed
API-getActivityById - First observed
API-getAIDataByPath - First observed
API-getAllChips - First observed
API-getAllEpochs - First observed
API-getAllNodes - First observed
API-getBridgingTransactionByHash - First observed
API-getBridgingTransactions - First observed
API-getChipById - First observed
API-getChipImageById - First observed
API-getDSLTotalRequests - First observed
API-getEpochAPYSnapshots - First observed
API-getEpochById - First observed
API-getEpochsAverageAPY - First observed
API-getEpochTransactionByHash - First observed
API-getFederatedAccountActivities - First observed
API-getFederatedActivityById - First observed
API-getFederatedNetworkActivities - First observed
API-getFederatedPlatformActivities - First observed
API-getNetworkActivities - First observed
API-getNetworkConfig - First observed
API-getNodeAssets - First observed
API-getNodeAvatarByAddress - First observed
API-getNodeByAddress - First observed
API-getNodeCountSnapshots - First observed
API-getNodeEventsByAddress - First observed
API-getNodeOperationProfitByAddress - First observed
API-getNodeOperationProfitSnapshots - First observed
API-getNodeRewardsByEpoch - First observed
API-getPlatformActivities - First observed
API-getRSS3TokenTotalSupply - First observed
API-getRSSActivityByPath - First observed
API-getStakerCountSnapshots - First observed
API-getStakerProfit - First observed
API-getStakerProfitSnapshots - First observed
API-getStakersAndNodes - First observed
API-getStakerStats - First observed
API-getStakingTransactionByHash - First observed
API-getStakingTransactions - First observed
API-getTokenTVL - First observed
API-health_check_api_v1_health_get
TDQS
With only one tool, there is no possibility of ambiguity between tools.
With a single tool, naming inconsistency is not applicable; the pattern is internally consistent.
A single tool for a server that likely should have many operations (RSS3 protocol) seems severely under-scoped.
The server provides only a meta-tool to get input schemas, with no actual domain operations, making it severely incomplete.
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
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
MCP server for AI dialogue using various LLM models via AceDataCloud
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server implementation that enables LLMs to interact with the Osmosis protocol, allowing for querying and transaction functionality through natural language.8MIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that fetches RSS feeds and shares them with LLMs, allowing AI assistants to access and present the latest news and articles from configured feeds.19-
- FlicenseNot gradedqualityCmaintenanceAn MCP server that enables deep internet research through natural language, supporting stdio and HTTP/SSE modes for flexible integration.3-
- AlicenseAqualityCmaintenance这是一个面向中文圈的MCP服务器,将中国互联网常用能力(如地图、快递、RSS、B站等)封装为标准MCP工具,方便AI Agent安全调用。132MIT
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/RSS3-Network/mcp-server-rss3'
If you have feedback or need assistance with the MCP directory API, please join our Discord server