AI アシスタントがモデル コンテキスト プロトコルを通じて Hive ブロックチェーンと対話できるようにする MCP サーバー。
このサーバーは、AI アシスタント (Claude など) と Hive ブロックチェーンの間にブリッジを提供し、AI モデルが次のことを実行できるようにします。
アカウント情報と履歴を取得する
ブログ投稿とディスカッションを取得する
タグまたはユーザーで投稿を取得する
コンテンツに投票し、投稿を作成する（適切に認証されている場合）
HIVEまたはHBDトークンを他のアカウントに送信する
Hiveキーを使用してメッセージを署名および検証する
暗号化されたメッセージを送受信する
Related MCP server: Bankless Onchain MCP Server
create-post - 適切な形式とタグを使用して新しい Hive 投稿を作成するように AI をガイドする構造化されたプロンプトを作成します。
analyze-account - Hiveアカウントの統計、投稿履歴、アクティビティパターンを分析するためのプロンプトを生成します
get_account_info - Hiveブロックチェーンアカウントの詳細情報を取得する
get_post_content - 著者とパームリンクで特定の投稿を取得する
get_posts_by_tag - タグとカテゴリ（トレンド、人気など）別に投稿を取得します
get_posts_by_user - 特定のユーザーまたはそのフィードから投稿を取得します
get_account_history - オプションの操作フィルタリングを使用してアカウントの取引履歴を取得します
get_chain_properties - 現在のHiveブロックチェーンのプロパティと統計を取得します
get_vesting_delegations - 特定のアカウントによって行われた権利確定委任のリストを取得します
vote_on_post - Hive コンテンツに投票する (投稿キーが必要)
create_post - Hiveブロックチェーンに新しいブログ投稿を作成する（投稿キーが必要）
create_comment - 既存の投稿にコメントするか、コメントに返信します（投稿キーが必要です）
send_token - HIVEまたはHBD暗号通貨を他のアカウントに送信する（有効なキーが必要）
sign_message - Hive秘密鍵を使用してメッセージに署名する
verify_signature - Hive公開鍵に対してメッセージの署名を検証する
encrypt_message - 特定のHiveアカウントのメッセージを暗号化する
decrypt_message - 特定のHiveアカウントから暗号化されたメッセージを復号化する
send_encrypted_message - トークン転送を使用して暗号化されたメッセージを送信する
get_encrypted_messages - アカウント履歴からメッセージを取得し、必要に応じて復号化する
MCP インスペクターは、サーバーのテストとデバッグのための対話型インターフェイスを提供します。
npx @modelcontextprotocol/inspector npx @gluneau/hive-mcp-server認証された操作 (投票、投稿、トークンの送信) を有効にするには、環境変数を設定する必要があります。
export HIVE_USERNAME=your-hive-username
export HIVE_POSTING_KEY=your-hive-posting-private-key # For content operations
export HIVE_ACTIVE_KEY=your-hive-active-private-key # For token transfers
export HIVE_MEMO_KEY=your-hive-memo-private-key # For encrypted messagingセキュリティに関する注意：秘密鍵を共有したり、バージョン管理にコミットしたりしないでください。環境変数を使用するか、安全な設定方法を使用してください。
このサーバーをClaude Desktopで使用するには:
Claude Desktopがインストールされていることを確認してください
Claude 構成ファイルを開くか作成します。
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
このサーバーを構成に追加します:
{
"mcpServers": {
"hive": {
"command": "npx",
"args": ["-y", "@gluneau/hive-mcp-server"],
"env": {
"HIVE_USERNAME": "your-hive-username",
"HIVE_POSTING_KEY": "your-hive-posting-private-key",
"HIVE_ACTIVE_KEY": "your-hive-active-private-key",
"HIVE_MEMO_KEY": "your-hive-memo-private-key"
}
}
}
}同じ JSON 構成が Windsurf ( windsurf_config.json内) と Cursor (バージョン >= 0.47 の場合は~/.cursor/mcp.json内) で機能します。
以前のバージョンでは、設定の MCP セクションで 1 行のコマンド形式を使用する必要があります: env HIVE_USERNAME=your-hive-username env HIVE_POSTING_KEY=your-hive-posting-private-key env HIVE_ACTIVE_KEY=your-hive-active-private-key env HIVE_MEMO_KEY=your-hive-memo-private-key npx -y @gluneau/hive-mcp-server
MCP クライアントに接続すると、次のような質問をすることができます。
「Hive の #photography タグでトレンドになっている投稿は何ですか?」
「ユーザー名「alice」の最近の投稿を表示してください」
「ボブの口座残高と詳細は？」
「『チャーリー』の取引履歴を取得する」
「「dave」さんの投稿に「my-awesome-post」というパーマリンクを付けて投票してもらえますか？」
「Hive で AI テクノロジーに関する新しい投稿を作成する」
「『ご協力ありがとうございます!』というメモを添えて、ユーザー「frank」に HIVE 1 つを送信します。」
「このメッセージに私のHive投稿キーで署名してください: '身元を確認しています'」
「現在のHiveブロックチェーンのプロパティは何ですか？」
「ユーザー「grace」が行った権利付与委任を表示してください」
「ユーザー 'alice' のこのメッセージを暗号化します: 'これは秘密のメッセージです'」
「'bob' からのこのメッセージを復号化してください: '#4f3a5b...'」
「『明日会おうね』という暗号化メッセージを『チャーリー』に送る」
「暗号化されたメッセージを表示して復号化してください」
「『デイブ』と交換した最後の10件の暗号化されたメッセージを取得する」
get_account_info残高、権限、投票権、その他の指標を含む Hive ブロックチェーン アカウントの詳細情報を取得します。
パラメータ:
username : 情報を取得するHiveユーザー名
get_post_content著者とパームリンクによって識別される特定の Hive ブログ投稿を取得します。
パラメータ:
author : 投稿の著者
permlink : 投稿のパームリンク
get_posts_by_tag特定のタグでフィルタリングされ、カテゴリ別に並べ替えられた Hive 投稿を取得します。
パラメータ:
category : 並べ替えのカテゴリ (トレンド、人気、作成など)
tag : 投稿をフィルタリングするタグ
limit : 返される投稿の数 (1-20)
get_posts_by_user特定の Hive ユーザーが作成した投稿、またはそのユーザーのフィード内の投稿を取得します。
パラメータ:
category : 取得するユーザー投稿の種類 (ブログまたはフィード)
username : 投稿を取得するHiveユーザー名
limit : 返される投稿の数 (1-20)
get_account_historyオプションの操作タイプ フィルタリングを使用して、Hive アカウントのトランザクション履歴を取得します。
パラメータ:
username : Hiveユーザー名
limit : 返される操作の数
operation_filter : フィルタリングする操作タイプのオプションリスト
get_chain_properties現在の Hive ブロックチェーンのプロパティと統計を取得します。
パラメータ: なし
get_vesting_delegations特定の Hive アカウントによって行われた権利付与委任のリストを取得します。
パラメータ:
username : 委任を受けるHiveアカウント
limit : 取得する委任の最大数
from : ページ区切りの開始アカウント（オプション）
vote_on_post設定された Hive アカウントを使用して、Hive 投稿に投票します (賛成または反対に投票します)。
パラメータ:
author : 投票する投稿の著者
permlink : 投票する投稿のパームリンク
weight : 投票の重み。-10000 (100% の反対票) から 10000 (100% の賛成票) まで
create_post設定されたアカウントを使用して、Hive ブロックチェーンに新しいブログ投稿を作成します。
パラメータ:
title : ブログ投稿のタイトル
body : ブログ投稿の内容（Markdown 対応）
tags : 投稿のタグ
報酬、受益者などに関するさまざまなオプション パラメータ。
create_comment既存の Hive 投稿にコメントを作成するか、別のコメントに返信します。
パラメータ:
parent_author : 返信先の投稿者またはコメントのユーザー名
parent_permlink : 返信先の投稿またはコメントのパーマリンク
body : コメントの内容 (Markdown 対応)
報酬、受益者などに関するさまざまなオプション パラメータ。
send_token設定されたアカウントを使用して、HIVE または HBD トークンを別の Hive アカウントに送信します。
パラメータ:
to : 受信者のHiveユーザー名
amount : 送信するトークンの量
currency : 送信する通貨（HIVE または HBD）
memo : 取引に含めるオプションのメモ
sign_message環境変数からの Hive 秘密キーを使用してメッセージに署名します。
パラメータ:
message : 署名するメッセージ
key_type : 使用するキーのタイプ（投稿、アクティブ、メモ）
verify_signatureHive 公開キーに対してデジタル署名を検証します。
パラメータ:
message_hash : メッセージのSHA-256ハッシュ（16進数形式）
signature : 検証する署名文字列
public_key : 検証する公開鍵
encrypt_messageメモ暗号化を使用して、特定の Hive アカウントのメッセージを暗号化します。
パラメータ:
message : 暗号化するメッセージ
recipient : 受信者のHiveユーザー名
decrypt_message特定の Hive アカウントから受信した暗号化されたメッセージを復号化します。
パラメータ:
encrypted_message : 暗号化されたメッセージ（#で始まる）
sender : 送信者のHiveユーザー名
send_encrypted_message小さなトークン転送を使用して、暗号化されたメッセージを Hive アカウントに送信します。
パラメータ:
message : 暗号化して送信するメッセージ
recipient : 受信者のHiveユーザー名
amount : 送信するHIVEの量（最小0.001、デフォルト: 0.001）
get_encrypted_messagesオプションの復号化を使用して、アカウント履歴から暗号化されたメッセージを取得します。
パラメータ:
username : 暗号化されたメッセージを取得するHiveユーザー名
limit : 取得するメッセージの最大数（デフォルト: 20）
decrypt : メッセージの復号化を試みるかどうか（デフォルト: false）
src/index.ts - メインサーバーの実装
src/tools/ - すべてのツールの実装
src/schemas/ - ツールパラメータの Zod スキーマ
src/utils/ - Hiveブロックチェーンとやりとりするためのユーティリティ関数
src/config/ - クライアント設定とログレベルの処理
@hiveio/dhive - Hive ブロックチェーン クライアント
@modelcontextprotocol/sdk - MCP SDK
zod - スキーマ検証
ISC
貢献を歓迎します！お気軽にプルリクエストを送信してください。
より詳しい貢献ガイドラインについては、 CONTRIBUTING.mdファイルを参照してください。
Create a comment on an existing Hive post or reply to another comment.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Content of the comment, can include Markdown formatting | |
| permalink | No | Optional custom permalink for your comment. If not provided, one will be generated | |
| allow_votes | No | Whether to allow votes on the comment | |
| percent_hbd | No | Optional percent of HBD in rewards (0-10000, where 10000 = 100%) | |
| beneficiaries | No | Optional list of beneficiaries to receive a portion of the rewards | |
| parent_author | Yes | Username of the post author or comment you're replying to | |
| parent_permlink | Yes | Permlink of the post or comment you're replying to | |
| max_accepted_payout | No | Optional maximum accepted payout (e.g. '1000.000 HBD') | |
| allow_curation_rewards | No | Whether to allow curation rewards |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the mutation action without detailing behavioral traits like authentication needs, rate limits, success/error states, or blockchain interaction specifics. This is insufficient for a write operation.
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?
One concise sentence that immediately communicates the tool's purpose with no extraneous words. It is front-loaded with the verb and resource.
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?
Despite detailed schema, the description lacks behavioral context (e.g., authentication, cost, success handling) and does not leverage the absence of annotations to provide a fuller picture. The tool has 9 parameters, so more context is needed.
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% with all parameters having descriptions. Description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 the verb 'create' and resource 'comment' with specific context ('on an existing Hive post or reply to another comment'). It distinguishes from sibling tool 'create_post', which creates entire posts, by specifying the comment action and ability to reply.
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?
Description implies usage for commenting or replying but lacks explicit when-to-use vs. alternatives like create_post. No exclusions, preconditions, or when-not-to scenarios are mentioned, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new blog post on the Hive blockchain using the configured account credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Content of the blog post, can include Markdown formatting | |
| tags | No | Tags for the post. Can be provided as comma-separated string 'blog,life,writing' or array | |
| title | Yes | Title of the blog post | |
| permalink | No | Optional custom permalink. If not provided, one will be generated from the title | |
| allow_votes | No | Whether to allow votes on the post | |
| percent_hbd | No | Optional percent of HBD in rewards (0-10000, where 10000 = 100%) | |
| beneficiaries | No | Optional list of beneficiaries to receive a portion of the rewards | |
| max_accepted_payout | No | Optional maximum accepted payout (e.g. '1000.000 HBD') | |
| allow_curation_rewards | No | Whether to allow curation rewards |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description minimally discloses 'using configured account credentials' but omits critical behavioral details like blockchain confirmation delays, error conditions, or irreversibility.
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?
Single sentence, no wasted words, highly efficient.
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?
Nine parameters and no output schema or annotations; the description fails to explain return values, error handling, or side effects, leaving significant gaps for a complex blockchain operation.
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 has 100% coverage, so description adds no additional meaning beyond what the schema provides. Baseline of 3 is appropriate.
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 the action (create), resource (blog post), and platform (Hive blockchain), and implicitly distinguishes from sibling tool 'create_comment'.
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?
No guidance on when to use this tool versus alternatives like 'create_comment', no prerequisites or context for when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decrypt an encrypted message received from a specific Hive account
| Name | Required | Description | Default |
|---|---|---|---|
| sender | Yes | Hive username of the sender | |
| encrypted_message | Yes | Encrypted message (starts with #) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fails to disclose behavioral traits such as authentication requirements, failure handling, or what happens if the message cannot be decrypted. It only states the action.
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?
Single sentence, no redundancy, front-loaded with key action and resource. Every word earns its place.
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?
No output schema, and description omits what the tool returns (presumably decrypted text). Also lacks context like prerequisites (e.g., having a decryption key). Incomplete for a simple but important operation.
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%, with both parameters described. The description adds no extra meaning beyond what the schema provides, so it meets the baseline but does not exceed.
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?
The description clearly states the verb 'decrypt' and the resource 'encrypted message from a specific Hive account', distinguishing it from sibling tools like 'encrypt_message' and 'get_encrypted_messages'.
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?
No guidance on when to use this tool versus alternatives (e.g., 'get_encrypted_messages' might be a prerequisite). The description does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encrypt a message for a specific Hive account using memo encryption
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to encrypt | |
| recipient | Yes | Hive username of the recipient |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only mentions 'memo encryption' without details on side effects, prerequisites, authentication needs, or whether the encrypted message is stored or returned.
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?
A single 12-word sentence efficiently conveys the tool's purpose with zero redundancy. It is front-loaded and scannable.
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?
Despite low complexity and no output schema, the description fails to mention the return value format (e.g., whether an encrypted string is returned). This leaves the agent guessing about the output.
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% with adequate parameter descriptions. The description adds only minimal context ('specific Hive account', 'memo encryption') that is already implied by the schema, so it meets baseline but does not excel.
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?
The description clearly states the action ('Encrypt'), the resource ('message'), the target ('specific Hive account'), and the method ('memo encryption'). It effectively distinguishes from siblings like decrypt_message.
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?
No guidance on when to use this tool versus alternatives such as send_encrypted_message or decrypt_message. The description does not provide any contextual advice on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves transaction history for a Hive account with optional operation type filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of operations to return | |
| username | Yes | Hive username | |
| operation_filter | No | Operation types to filter for. Can be provided as an array ['transfer', 'vote'] or a comma-separated string 'transfer,vote' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'retrieves' implying read-only, but does not disclose behavioral traits such as required permissions, rate limits, pagination behavior, or whether results are sorted by time.
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?
The description is a single sentence of 12 words, front-loading the action and resource. No extraneous information, perfectly concise.
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?
No output schema exists, so the description should compensate by describing the return format. It does not mention the structure of the returned transaction history (e.g., array of operations, fields included), pagination, or error handling. The description is adequate for basic understanding but lacks completeness for a tool with no output schema.
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 description coverage is 100%, with all parameters already described. The description adds 'optional operation type filtering' which aligns with the operation_filter parameter, but does not add significant new semantic value beyond what the schema provides.
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?
The description clearly states the tool retrieves transaction history for a Hive account, with optional operation type filtering. It specifies the verb and resource, and distinguishes from sibling tools like get_account_info (account details) and get_posts_by_user (user posts).
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?
No guidance on when to use this tool versus alternatives, nor any context on when not to use it. For example, it does not clarify that other tools might be more appropriate for specific operation types or that it is a read-only operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches detailed information about a Hive blockchain account including balance, authority, voting power, and other account metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Hive username to fetch information for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must shoulder the burden. It clarifies it's a read operation and lists common return fields, but does not disclose error handling, rate limits, or network behavior.
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?
Single sentence, front-loaded with key information, no redundancy.
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?
Good detail for a simple read tool with one parameter. Lists example return fields, though absence of output schema and error conditions not covered.
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 'username'. The description does not add additional meaning beyond the schema's description, so baseline 3 is appropriate.
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?
Clearly states it fetches detailed information about a Hive blockchain account and lists example metrics, distinguishing it from siblings like get_account_history which retrieves history.
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?
No guidance on when to use this tool versus alternatives like get_account_history or get_chain_properties. The description does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch current Hive blockchain properties and statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only says 'Fetch' without disclosing any behavioral traits like rate limits, data freshness, or side effects.
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?
The description is a single sentence with no wasted words, front-loading the core purpose efficiently.
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?
No output schema exists, so the description should explain what the tool returns. It does not describe the specific properties or statistics, leaving the agent guessing about the output format.
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?
There are no parameters, and schema coverage is 100%. Baseline for 0 parameters is 4, and the description adds no meaningful parameter semantics beyond the schema.
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 fetches Hive blockchain properties and statistics, with a specific verb and resource. It distinguishes from sibling tools which focus on posts, accounts, messages, etc.
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?
No explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool's purpose, but no when-not or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve encrypted messages from account history with optional decryption
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of messages to retrieve | |
| decrypt | No | Whether to attempt decryption of messages | |
| username | No | Hive username to fetch encrypted messages for (defaults to configured account if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'optional decryption' but does not explain what decryption entails (e.g., requires keys, may fail) or whether the operation is read-only. The retrieval aspect is clear, but the decryption behavior is underspecified.
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?
Description is extremely concise at 8 words. It wastes no words, but could benefit from a bit more structure or detail. Still, it is efficiently front-loaded and directly states the action.
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?
For a tool with 3 parameters and no output schema, the description covers the core functionality. However, it lacks details on ordering, pagination behavior (limit), and prerequisites for decryption. It is adequate but not fully complete for an agent to use effectively without additional inference.
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% with descriptions for all three parameters. The description adds 'optional decryption' which aligns with the decrypt parameter, but does not add significant new meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
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 specifies the verb 'Retrieve' and the resource 'encrypted messages from account history', with optional decryption. It distinguishes from sibling tools like get_account_history and decrypt_message by focusing on encrypted messages and combining retrieval with optional decryption.
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?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that decrypt_message might be used separately if decryption is always needed, or that get_account_history is for broader history. The description lacks use case differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a specific Hive blog post identified by author and permlink, including the post title, content, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| author | Yes | Author of the post | |
| permlink | Yes | Permlink of the post |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states retrieval of data, omitting error handling (e.g., if post not found), rate limits, or any side effects.
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?
Single sentence with no unnecessary words, front-loaded with the action verb 'Retrieves'.
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?
For a simple retrieval tool with two required parameters and no output schema, the description covers basic purpose and output. However, it lacks error handling context and usage recommendations, making it adequate but not thorough.
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%, so the schema already documents parameters. The description adds minor value by mentioning 'author and permlink' in context, but does not explain their format or restrictions beyond the schema.
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?
The description clearly states the tool retrieves a single Hive blog post using author and permlink, specifying included content. It distinguishes from sibling tools like get_posts_by_tag and get_posts_by_user that retrieve multiple posts.
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?
The description implies usage when author and permlink are known, but does not provide explicit when-not-to-use guidance or compare with alternatives like get_posts_by_user or get_posts_by_tag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves Hive posts filtered by a specific tag and sorted by a category like trending, hot, or created.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | The tag to filter posts by | |
| limit | No | Number of posts to return (1-20) | |
| category | Yes | Sorting category for posts (e.g. trending, hot, created) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states the basic retrieval function. It does not mention error handling for invalid tags/categories, response format, or whether results are paginated. The sort order is implied but not comprehensively described.
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?
The description is a single, front-loaded sentence with no superfluous words. Every part contributes to the core purpose, making it highly concise.
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 absence of annotations and output schema, the description is too brief to fully enable correct use. It lacks details on return values, pagination, and edge cases. The presence of sibling tools further demands more contextual guidance.
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?
The input schema covers all parameters with descriptions (100% coverage), so the description adds minimal semantic value beyond 'filtered' and 'sorted'. Baseline of 3 is appropriate as the description does not hinder understanding.
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?
The description clearly states the verb ('Retrieves') and the resource ('Hive posts'), specifying the filtering by tag and sorting by category. It distinguishes itself from sibling tools like 'get_posts_by_user' and 'get_post_content' by focusing on tag-based queries.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., get_posts_by_user for user-filtered posts). It does not mention contexts where this tool is inappropriate or highlight limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves posts authored by or in the feed of a specific Hive user.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of posts to return (1-20) | |
| category | Yes | Type of user posts to fetch (blog = posts by user, feed = posts from users they follow) | |
| username | Yes | Hive username to fetch posts for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It only describes the basic operation but omits details like pagination, ordering, authentication requirements, or side effects. A retrieval tool should at least indicate read-only nature.
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?
Single sentence that is front-loaded with the action, resource, and scope. No wasted words.
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 no output schema, the description should hint at return values and behavior. It explains the two types but lacks pagination info, default limit mention (though in schema), and return format. Adequate but with gaps.
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% with descriptions for all parameters. The description adds value by explaining the difference between blog and feed categories, but does not add meaning beyond the schema for limit or username.
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 verb (retrieves), resource (posts), and scope (authored by or in the feed of a specific Hive user). It distinguishes the two category types (blog vs feed) and differentiates from sibling tools like get_posts_by_tag.
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?
Description explains the two categories (blog = posts by user, feed = posts from users they follow), which implicitly guides usage. However, it lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like get_posts_by_tag or get_post_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of vesting delegations made by a specific Hive account
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Optional starting account for pagination | |
| limit | No | Maximum number of delegations to retrieve | |
| username | Yes | Hive account to get delegations for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states 'get a list', without specifying if the call is read-only, requires authentication, or has any side effects. The read-only nature is implicit but not explicit.
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?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for the tool's simplicity.
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 no output schema and no annotations, the description is minimally complete. It does not explain the return format or pagination behavior, but the tool is straightforward. Some gaps exist, but it is not severely incomplete.
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%, meaning all parameter descriptions are already present in the schema. The description adds no extra semantic value 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get', the resource 'vesting delegations', and the scope 'made by a specific Hive account'. It effectively distinguishes from sibling tools, which are all different operations.
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?
The description implies usage for retrieving vesting delegations but provides no explicit guidance on when to use or avoid this tool, nor does it mention alternatives. Usage is implied by the domain context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an encrypted message to a Hive account using a small token transfer
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Amount of HIVE to send (minimum 0.001) | |
| message | Yes | Message to encrypt and send | |
| recipient | Yes | Hive username of the recipient |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the token transfer mechanism (implying cost) but omits encryption method, authentication needs, on-chain storage, or potential side effects like token deduction.
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?
A single, direct sentence with no unnecessary words. It is concise, though perhaps too brief given the need for more behavioral context.
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?
With 17 sibling tools and no output schema or annotations, the description lacks completeness. It does not explain return value, prerequisites (e.g., account keys), or encryption details, making it insufficient for an agent to use confidently.
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?
Input schema covers all parameters with descriptions (100% coverage). The description adds no additional meaning beyond the schema; it only restates the tool's purpose without detailing parameters.
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?
The description clearly states the tool's action: sending an encrypted message to a Hive account using a token transfer. It differentiates from siblings like 'send_token' (no message) and 'encrypt_message' (no send).
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?
No guidance on when to use this tool versus alternatives such as 'create_comment' or 'send_token'. No explicit context about prerequisites or situations to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send HIVE or HBD tokens to another Hive account using the configured account credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient Hive username | |
| memo | No | Optional memo to include with the transaction | |
| amount | Yes | Amount of tokens to send | |
| currency | Yes | Currency to send: HIVE or HBD |
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 mentions 'using the configured account credentials' but fails to detail destructive nature (sending is a write operation), potential errors (e.g., insufficient balance), or rate limits. The description is too brief for a financial transaction tool.
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?
The description is a single, clear sentence with no extraneous words. While concise, it could include a brief front-loaded summary of the key action.
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?
The tool has no output schema, and the description fails to explain what happens after sending (e.g., success confirmation, transaction ID). It neither describes return format nor side effects, leaving the agent uninformed about the outcome.
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 description coverage is 100%, so the schema already documents all parameters. The description adds no further semantic context beyond the schema, such as explanation of memo or amount constraints. Baseline score of 3 is appropriate.
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?
The description clearly states the action (send), the resource (HIVE or HBD tokens), and the context (to another Hive account). It distinguishes from sibling tools like create_comment or vote_on_post, and even from send_encrypted_message by specifying the currency types.
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?
The description does not provide guidance on when to use this tool versus alternatives like send_encrypted_message or other transfer methods. No when-not-to-use or prerequisite information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign a message using a Hive private key from environment variables.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to sign (must not be empty) | |
| key_type | No | Type of key to use: 'posting', 'active', or 'memo'. Defaults to 'posting' if not specified. | posting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses key source but lacks details on security implications, failure modes, or side effects.
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?
Single sentence, concise. Could benefit from slight restructuring to front-load key info, but effective.
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?
Adequate for a simple tool with 2 params and no output schema. Missing return value description and potential constraints.
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 description coverage is 100%, so baseline 3. Description adds no extra parameter-specific meaning beyond 'using a Hive private key from environment variables'.
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 action (sign), resource (message), and key source (environment variables). Distinguishes from sibling tools like decrypt_message or verify_signature.
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?
Implied usage when signing a message with Hive key from env vars, but no explicit context on when to use vs alternatives like verify_signature or encrypt_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a digital signature against a Hive public key
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | Signature string to verify | |
| public_key | Yes | Public key to verify against (with or without the STM prefix) | |
| message_hash | Yes | The SHA-256 hash of the message in hex format (64 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description only states the basic operation and does not disclose behavioral details such as what happens on verification failure (error/return false), required permissions, or response format.
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?
The description is a single short sentence with no wasted words. However, it could benefit from front-loading the most critical information like return type.
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 no output schema, the description should explain the return value (e.g., boolean) or error behavior, but it does not. The minimal description leaves gaps for an AI agent to understand the tool's full usage.
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 description coverage is 100%, so each parameter is already described in the schema. The tool description adds no extra parameter meaning beyond what the schema provides.
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?
The description 'Verify a digital signature against a Hive public key' clearly states the action and resource, distinguishing it from sibling tools like create_comment or sign_message that involve different operations.
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?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include sign_message (related) and various retrieval tools, but no differentiation or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vote on a Hive post (upvote or downvote) using the configured Hive account.
| Name | Required | Description | Default |
|---|---|---|---|
| author | Yes | Author of the post to vote on | |
| weight | Yes | Vote weight from -10000 (100% downvote) to 10000 (100% upvote) | |
| permlink | Yes | Permlink of the post to vote on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'using the configured Hive account' but does not disclose authentication requirements, rate limits, or behavioral constraints (e.g., cannot vote on same post twice).
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?
The description is a single, concise sentence that front-loads the core purpose. Every word is necessary and no extraneous content.
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?
While the tool is simple with 3 fully-documented parameters, the description lacks context about prerequisites (e.g., need a configured account) and behavioral details. It is minimally complete but has gaps.
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 description coverage is 100%, so the schema already documents each parameter's meaning. The description adds no additional value beyond the schema, resulting in a baseline score of 3.
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?
The description clearly states the verb 'vote', the resource 'Hive post', and the action types 'upvote or downvote'. It distinguishes this tool from siblings as the only voting tool.
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?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided. The description simply states what it does without any usage instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_commentcreate_postdecrypt_messageencrypt_messageget_account_historyget_account_infoget_chain_propertiesget_encrypted_messagesget_post_contentget_posts_by_tagget_posts_by_userget_vesting_delegationssend_encrypted_messagesend_tokensign_messageverify_signaturevote_on_postScored across 17 tools
Each tool targets a distinct resource or action on the Hive blockchain, such as posts, comments, voting, messaging, token transfers, account info, blockchain properties, and signing. No two tools have overlapping purposes; even related tools like encrypt/decrypt and send/retrieve encrypted messages are clearly differentiated.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_post, get_account_info, send_token). Verbs are appropriately chosen for the action, and there is no mixing of styles (e.g., camelCase or other conventions).
With 17 tools, the server covers a comprehensive range of Hive operations without being overwhelming. Each tool serves a clear purpose, and the count is well-scoped for the domain's complexity.
The tool set covers major CRUD-like operations for posts, comments, voting, messaging, token transfers, account details, and blockchain properties. However, there is no tool for updating posts (editing) or delegating HP, which are notable gaps for a full-featured Hive interface.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Context and control for any AI. Agent identity, scoped access, and proof across tools.
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
