Сервер MCP, который позволяет помощникам на основе искусственного интеллекта взаимодействовать с блокчейном Hive через протокол контекста модели.
Этот сервер обеспечивает мост между помощниками ИИ (такими как Клод) и блокчейном Hive, позволяя моделям ИИ:
Извлечь информацию об учетной записи и историю
Получить записи и обсуждения в блогах
Получить сообщения по тегу или пользователю
Голосуйте за контент и создавайте посты (при условии надлежащей аутентификации)
Отправляйте токены HIVE или HBD на другие счета
Подписывайте и проверяйте сообщения с помощью ключей Hive
Отправляйте и получайте зашифрованные сообщения
Related MCP server: Bankless Onchain MCP Server
create-post — создает структурированную подсказку, помогающую ИИ создать новую публикацию 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
Откройте или создайте файл конфигурации Клода:
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).
В предыдущих версиях вам придется использовать формат команды из 1 строки в разделе MCP настроек: 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, вы можете задавать такие вопросы, как:
«Какие публикации с тегом #photography пользуются наибольшим спросом на Hive?»
«Покажи мне последние сообщения пользователя 'alice'»
«Каков баланс и реквизиты счета для «Боба»?»
«Получить историю транзакций для 'charlie'»
«Можете ли вы проголосовать за пост пользователя 'dave' с постоянной ссылкой 'my-awesome-post'?»
«Создать новый пост на Hive о технологии искусственного интеллекта»
«Отправить 1 HIVE пользователю 'frank' с сообщением 'Спасибо за помощь!'»
«Подпишите это сообщение моим ключом публикации Hive: «Проверка моей личности»»
«Каковы текущие свойства блокчейна Hive?»
«Покажите мне делегирование полномочий, сделанное пользователем 'grace'»
«Зашифровать это сообщение для пользователя 'alice': 'Это секретное сообщение'»
«Расшифруйте это сообщение от 'bob': '#4f3a5b...'»
«Отправьте зашифрованное сообщение «Чарли» со словами «Давай встретимся завтра»»
«Покажи мне мои зашифрованные сообщения и расшифруй их»
«Получить последние 10 зашифрованных сообщений, которыми я обменивался с 'dave'»
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_signatureПроверьте цифровую подпись с помощью открытого ключа Hive.
Параметры:
message_hash : хэш SHA-256 сообщения в шестнадцатеричном формате
signature : Строка подписи для проверки
public_key : Открытый ключ для проверки
encrypt_messageЗашифруйте сообщение для определенной учетной записи Hive, используя шифрование Memo.
Параметры:
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 - Проверка схемы
МСК
Вклады приветствуются! Пожалуйста, не стесняйтесь отправлять запрос на включение.
Более подробные правила внесения вклада см. в файле 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.
