MCP 服务器使 AI 助手能够通过模型上下文协议与 Hive 区块链进行交互。
该服务器在 AI 助手（如 Claude）和 Hive 区块链之间架起了一座桥梁，使 AI 模型能够：
获取帐户信息和历史记录
检索博客文章和讨论
按标签或用户获取帖子
对内容进行投票并创建帖子（经过正确身份验证后）
将 HIVE 或 HBD 代币发送到其他账户
使用 Hive 密钥对消息进行签名和验证
发送和接收加密消息
Related MCP server: Bankless Onchain MCP Server
create-post - 创建结构化提示，指导 AI 创建具有正确格式和标签的新 Hive 帖子
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 Inspector 提供了一个用于测试和调试服务器的交互式界面：
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 (在~/.cursor/mcp.json中，版本 >= 0.47)。
在以前的版本中，您必须在设置的 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’的近期帖子”
“‘bob’的账户余额和详细信息是多少？”
“获取‘charlie’的交易历史记录”
“您能为‘dave’的帖子点赞，并将永久链接设为‘my-awesome-post’吗？”
“在 Hive 上创建关于 AI 技术的新帖子”
“向用户‘frank’发送 1 个 HIVE，并附上备注‘感谢您的帮助！’”
“使用我的 Hive 发布密钥签署此消息：‘验证我的身份’”
“当前的 Hive 区块链属性是什么？”
“显示用户‘grace’授予的授权委托”
“为用户‘alice’加密此消息：‘这是一条秘密消息’”
“解密来自‘bob’的此消息：‘#4f3a5b...’”
“向‘查理’发送一条加密信息，内容是‘我们明天见面吧’”
“显示我的加密信息并解密它们”
“获取我与‘dave’交换的最后 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 用户撰写的帖子或该用户 feed 中的帖子。
参数：
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_signature根据 Hive 公钥验证数字签名。
参数：
message_hash ：消息的 SHA-256 哈希值（十六进制格式）
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 - 模式验证
国际学习中心
欢迎贡献代码！欢迎提交 Pull 请求。
请参阅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.
