A
licenseB
qualityD
maintenanceA Model Context Protocol server that enables interaction with Snapshot.org, providing tools to query Snapshot spaces, proposals, and users through natural language.
5
8 npm
MIT
MCP SNS Server
by baolongt
mcp-sns-server MCP サーバー
インターネットコンピュータ上のDAOと対話するためのモデルコンテキストプロトコルサーバー
これはTypeScriptベースのMCPサーバーで、Service Nervous System（SNS）DAOへのインターフェースを実装しています。分散型自律組織と連携するためのツールを提供することで、MCPの中核概念を実証しています。
設定
シードフレーズをenvファイルに追加する
cp .env.example .envRelated MCP server: AMOCA Solana MCP Server
特徴
ツール
list_proposals- 特定のDAOのすべての提案を一覧表示するDAO名をパラメータとして受け取る
指定されたDAOからの提案のリストを返します
list_votable_neurons- DAO 内のユーザーのすべての投票可能なニューロンを一覧表示しますDAO名とプリンシパルIDをパラメータとして受け取ります
提案に投票できるニューロンを返す
get_system_parameters- DAO のすべての構成パラメータを一覧表示しますDAO名をパラメータとして受け取る
指定されたDAOのシステムパラメータを返します
wallet- ユーザーのウォレット情報を取得する現在のウォレットのプリンシパルIDを返します
vote_proposal- 提案に投票するDAO名、プリンシパルID、ニューロンID、提案ID、投票優先順位を取得します。
提案に対して賛成、反対、または未指定で投票できます
DAOガバナンスシステムに投票を登録する
発達
依存関係をインストールします:
npm installサーバーを構築します。
npm run build自動リビルドを使用した開発の場合:
npm run watchインストール
Claude Desktop で使用するには、サーバー設定を追加します。
MacOS の場合: ~/Library/Application Support/Claude/claude_desktop_config.json Windows の場合: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"mcp-sns-server": {
"command": "/path/to/mcp-sns-server/build/index.js"
}
}
}デバッグ
MCPサーバーはstdio経由で通信するため、デバッグが困難になる場合があります。パッケージスクリプトとして提供されているMCP Inspectorの使用をお勧めします。
npm run inspectorインスペクターは、ブラウザでデバッグ ツールにアクセスするための URL を提供します。
Available Tools
5 toolsget_system_parametersC
List all configuration parameters
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| daoName | Yes | DAO name |
TDQS
C2.6/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits like idempotency or security implications. The description only states 'List all configuration parameters' without any additional context about side effects, error conditions, or access requirements.
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 very concise with a single sentence, but it lacks some useful detail. It is not verbose, but could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the tool is not fully specified. The agent cannot infer what exactly is returned (e.g., list of parameter names, key-value pairs), which reduces completeness given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the single parameter 'daoName' as 'DAO name'. The description does not add any new meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 verb 'List' and the resource 'configuration parameters', making the tool's purpose apparent. Although it could specify that parameters are scoped to a DAO, it distinguishes itself from siblings like 'list_proposals' and 'vote_proposal' which cover different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or contexts that would help an agent decide effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_proposalsC
List all proposals
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| daoName | Yes | DAO name |
TDQS
C2.7/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 full burden. It doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what the output format might be. The description is minimal and adds no behavioral context beyond the basic action.
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 extremely concise with just three words, front-loaded and zero waste. It efficiently states the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a sibling tool, the description is incomplete. It doesn't explain the relationship to 'list_votable_neurons', output details, or behavioral aspects. For a tool with one parameter and no structured support, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'daoName' documented as 'DAO name'. The description doesn't add any meaning beyond this, such as explaining what a DAO is or how the parameter affects the listing. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all proposals' clearly states the action (list) and resource (proposals), but it's vague about scope and doesn't differentiate from the sibling tool 'list_votable_neurons'. It doesn't specify whether this lists proposals across all DAOs or just for a specific DAO, which the parameter suggests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling 'list_votable_neurons'. The description doesn't mention prerequisites, alternatives, or context for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_votable_neuronsC
List all votable neurons
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| daoName | No | DAO name | |
| principalId | Yes | Principal ID |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like (especially since there's no output schema).
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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a list operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'votable neurons' are, how results are returned, or any prerequisites, leaving significant gaps for the agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (daoName and principalId). The description adds no additional meaning about parameters beyond what's in the schema, such as explaining what 'votable neurons' are in relation to these inputs. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('List') and resource ('votable neurons'), making the purpose understandable. However, it doesn't differentiate from the sibling tool 'list_proposals' (which presumably lists proposals rather than neurons), so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention the sibling tool 'list_proposals' or any other context for choosing between them, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vote_proposalC
vote on a proposal
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| vote | Yes | Vote (yes, no, unspecified) | |
| daoName | Yes | DAO name | |
| neuronId | Yes | Neuron ID | |
| proposalId | Yes | Proposal ID | |
| principalId | Yes | Principal ID |
TDQS
C2.1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention side effects like irreversibility, authorization requirements, or voting power constraints. The description is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase, which is too brief. While concise, it lacks structure and does not earn its place by providing useful information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 required parameters, no output schema, and no annotations, the description is critically incomplete. It does not explain return values, voting mechanics, or constraints, leaving the agent without crucial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with basic descriptions. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'vote on a proposal' states a verb and resource, but it is generic. It does not differentiate from sibling tools like list_proposals or get_system_parameters, and lacks specificity about the context (e.g., DAO voting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring a valid neuron or DAO membership, nor does it specify appropriate contexts for voting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
walletB
get my wallet
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'get' implies a read-only operation, but without annotations, it does not explicitly state whether the tool modifies state or requires authentication. The behavior is straightforward but not fully disclosed.
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 a single concise sentence that directly communicates the tool's purpose. There is no unnecessary information, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain return values or what the wallet contains. Given no output schema, the description should provide more context about the result, but it remains vague.
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?
There are no parameters, so the input schema provides complete coverage. The description adds no parameter information, but with zero parameters, the baseline of 4 is appropriate.
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?
Description 'get my wallet' clearly indicates retrieving the user's wallet. It is distinct from sibling tools like list_proposals or vote_proposal, but lacks elaboration on what 'wallet' specifically refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention context or prerequisites for using the wallet retrieval.
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.
5 tool updates
v1.0.0- First observed
get_system_parameters - First observed
list_proposals - First observed
list_votable_neurons - First observed
vote_proposal - First observed
wallet
TDQS
B3/5.0
Scored across 5 tools
Disambiguation5/5
Each tool targets a distinct function: system parameters, proposals, neurons, voting, and wallet. There is no overlap or ambiguity in their purposes.
Naming Consistency3/5
Tool names mix get_, list_, and a bare noun (wallet). While most follow verb_noun, 'wallet' lacks a verb and 'vote_proposal' uses a verb_noun order that differs from the list prefix. Inconsistent pattern.
Tool Count5/5
With 5 tools, the server covers core SNS governance actions without being excessive or sparse. Each tool serves a clear purpose.
Completeness3/5
Domain covers governance basics but lacks detail: no tool to get a single proposal's details, no neuron management beyond listing, and wallet is rudimentary. Missing update/delete or register operations.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Model Context Protocol server for Studex tools, notifications, and profile integrations
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI models to interact with the Solana blockchain, providing RPC methods, wallet management, DeFi trading capabilities, and Helius API integration for enhanced Solana development.5MIT
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI assistants to access Flow blockchain data and perform operations such as checking balances, resolving domains, executing scripts, and submitting transactions.1-
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables interactions with the Hedera network, providing tools for wallet creation, balance checking, transaction building, and sending signed transactions.3-