Un servidor MCP que permite a los asistentes de IA interactuar con la cadena de bloques Hive a través del Protocolo de Contexto de Modelo.
Este servidor proporciona un puente entre los asistentes de IA (como Claude) y la cadena de bloques Hive, lo que permite a los modelos de IA:
Obtener información y el historial de la cuenta
Recuperar publicaciones y debates del blog
Obtener publicaciones por etiqueta o usuario
Votar sobre el contenido y crear publicaciones (cuando esté debidamente autenticado)
Envía tokens HIVE o HBD a otras cuentas
Firmar y verificar mensajes con claves de Hive
Enviar y recibir mensajes cifrados
Related MCP server: Bankless Onchain MCP Server
create-post : crea un mensaje estructurado para guiar a la IA en la creación de una nueva publicación de Hive con el formato y las etiquetas correctos.
analyze-account : genera un mensaje para analizar las estadísticas, el historial de publicaciones y los patrones de actividad de una cuenta de Hive.
get_account_info - Obtenga información detallada sobre una cuenta de blockchain de Hive
get_post_content - Recupera una publicación específica por autor y enlace permanente
get_posts_by_tag - Recupera publicaciones por etiqueta y categoría (tendencia, popular, etc.)
get_posts_by_user - Obtener publicaciones de un usuario específico o de su feed
get_account_history : obtiene el historial de transacciones de una cuenta con filtrado de operaciones opcional
get_chain_properties : recupera las propiedades y estadísticas actuales de la cadena de bloques de Hive
get_vesting_delegations - Obtener una lista de delegaciones de derechos realizadas por una cuenta específica
vote_on_post - Vota sobre el contenido de Hive (requiere clave de publicación)
create_post : crea nuevas publicaciones de blog en la cadena de bloques Hive (requiere una clave de publicación)
create_comment - Comentar publicaciones existentes o responder a comentarios (requiere clave de publicación)
send_token - Envía criptomonedas HIVE o HBD a otras cuentas (requiere una clave activa)
sign_message - Firma un mensaje usando una clave privada de Hive
verify_signature - Verificar la firma de un mensaje con una clave pública de Hive
encrypt_message : cifra un mensaje para una cuenta específica de Hive
decrypt_message : descifra un mensaje cifrado de una cuenta específica de Hive
send_encrypted_message - Envía un mensaje cifrado mediante una transferencia de token
get_encrypted_messages : recupera y, opcionalmente, descifra mensajes del historial de la cuenta
El Inspector MCP proporciona una interfaz interactiva para probar y depurar el servidor:
npx @modelcontextprotocol/inspector npx @gluneau/hive-mcp-serverPara habilitar operaciones autenticadas (votación, publicación, envío de tokens), deberá configurar variables de entorno:
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 messagingNota de seguridad : Nunca comparta sus claves privadas ni las envíe al control de versiones. Utilice variables de entorno o un enfoque de configuración seguro.
Para utilizar este servidor con Claude Desktop:
Asegúrese de tener instalado Claude Desktop
Abra o cree el archivo de configuración de Claude:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Ventanas: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Añade este servidor a tu configuración:
{
"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"
}
}
}
}La misma configuración JSON funciona para Windsurf (en windsurf_config.json ) y para Cursor (en ~/.cursor/mcp.json para la versión >= 0.47).
En versiones anteriores, tendrás que usar el formato de comando de 1 línea en la sección MCP de Configuración: 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
Una vez conectado a un cliente MCP, puede hacer preguntas como:
"¿Cuáles son las publicaciones de tendencia en la etiqueta #fotografía en Hive?"
Muéstrame las publicaciones recientes del usuario 'alice'
"¿Cuál es el saldo y los detalles de la cuenta de 'bob'?"
Obtener el historial de transacciones de 'Charlie'
"¿Podrías votar positivamente la publicación de 'dave' con el enlace permanente 'my-awesome-post'?"
"Crear una nueva publicación en Hive sobre tecnología de IA"
Envía 1 HIVE al usuario 'frank' con el mensaje '¡Gracias por tu ayuda!'
Firma este mensaje con mi clave de publicación de Hive: "Verificando mi identidad".
¿Cuáles son las propiedades actuales de la cadena de bloques Hive?
"Muéstrame las delegaciones de derechos realizadas por el usuario 'grace'"
Cifrar este mensaje para la usuaria 'alice': 'Este es un mensaje secreto'.
"Descifra este mensaje de 'bob': '#4f3a5b...'"
Envía un mensaje cifrado a 'Charlie' diciendo: 'Nos vemos mañana'.
"Muéstrame mis mensajes cifrados y descifralos"
Obtener los últimos 10 mensajes cifrados que intercambié con 'dave'
get_account_infoObtiene información detallada sobre una cuenta de blockchain de Hive, incluido el saldo, la autoridad, el poder de voto y otras métricas.
Parámetros:
username : nombre de usuario de Hive para obtener información
get_post_contentRecupera una publicación de blog específica de Hive identificada por autor y enlace permanente.
Parámetros:
author : Autor de la publicación
permlink : Enlace permanente de la publicación
get_posts_by_tagRecupera publicaciones de Hive filtradas por una etiqueta específica y ordenadas por una categoría.
Parámetros:
category : Clasificación por categoría (tendencia, popular, creado, etc.)
tag : La etiqueta para filtrar publicaciones por
limit : Número de publicaciones a devolver (1-20)
get_posts_by_userRecupera publicaciones creadas por o en el feed de un usuario específico de Hive.
Parámetros:
category : Tipo de publicaciones de usuario a buscar (blog o feed)
username : nombre de usuario de Hive para obtener publicaciones
limit : Número de publicaciones a devolver (1-20)
get_account_historyRecupera el historial de transacciones de una cuenta de Hive con filtrado de tipo de operación opcional.
Parámetros:
username : nombre de usuario de Hive
limit : Número de operaciones a devolver
operation_filter : Lista opcional de tipos de operaciones para filtrar
get_chain_propertiesObtenga propiedades y estadísticas actuales de la cadena de bloques Hive.
Parámetros: Ninguno
get_vesting_delegationsObtenga una lista de delegaciones de derechos realizadas por una cuenta específica de Hive.
Parámetros:
username : Cuenta de Hive para obtener delegaciones para
limit : Número máximo de delegaciones a recuperar
from : Cuenta de inicio opcional para paginación
vote_on_postVota una publicación de Hive (a favor o en contra) usando la cuenta de Hive configurada.
Parámetros:
author : Autor de la publicación a votar
permlink : Enlace permanente de la publicación para votar
weight : Peso del voto de -10000 (100% votos negativos) a 10000 (100% votos positivos)
create_postCree una nueva publicación de blog en la cadena de bloques Hive utilizando la cuenta configurada.
Parámetros:
title : Título de la entrada del blog
body : Contenido de la entrada del blog (compatible con Markdown)
tags : Etiquetas para la publicación
Varios parámetros opcionales para recompensas, beneficiarios, etc.
create_commentCrea un comentario en una publicación existente de Hive o responde a otro comentario.
Parámetros:
parent_author : Nombre de usuario del autor de la publicación o del comentario al que estás respondiendo
parent_permlink : Enlace permanente de la publicación o comentario al que estás respondiendo
body : Contenido del comentario (compatible con Markdown)
Varios parámetros opcionales para recompensas, beneficiarios, etc.
send_tokenEnvía tokens HIVE o HBD a otra cuenta de Hive usando la cuenta configurada.
Parámetros:
to : Nombre de usuario de Hive del destinatario
amount : Cantidad de tokens a enviar
currency : Moneda a enviar (HIVE o HBD)
memo : memo opcional para incluir con la transacción
sign_messageFirme un mensaje utilizando una clave privada de Hive desde variables de entorno.
Parámetros:
message : Mensaje para firmar
key_type : Tipo de clave a utilizar (publicación, activa o memo)
verify_signatureVerificar una firma digital con una clave pública de Hive.
Parámetros:
message_hash : El hash SHA-256 del mensaje en formato hexadecimal
signature : Cadena de firma para verificar
public_key : Clave pública para verificar
encrypt_messageCifrar un mensaje para una cuenta específica de Hive usando el cifrado de notas.
Parámetros:
message : Mensaje a cifrar
recipient : nombre de usuario de Hive del destinatario
decrypt_messageDescifrar un mensaje cifrado recibido de una cuenta específica de Hive.
Parámetros:
encrypted_message : Mensaje cifrado (comienza con #)
sender : nombre de usuario de Hive del remitente
send_encrypted_messageEnvía un mensaje cifrado a una cuenta de Hive mediante una pequeña transferencia de token.
Parámetros:
message : Mensaje para cifrar y enviar
recipient : nombre de usuario de Hive del destinatario
amount : Cantidad de HIVE a enviar (mínimo 0,001, predeterminado: 0,001)
get_encrypted_messagesRecupere mensajes cifrados del historial de la cuenta con descifrado opcional.
Parámetros:
username : nombre de usuario de Hive para obtener mensajes cifrados
limit : Número máximo de mensajes a recuperar (predeterminado: 20)
decrypt : si se debe intentar descifrar los mensajes (predeterminado: falso)
src/index.ts - Implementación del servidor principal
src/tools/ - Implementación de todas las herramientas
src/schemas/ - Esquemas Zod para parámetros de herramientas
src/utils/ - Funciones de utilidad para interactuar con la cadena de bloques Hive
src/config/ - Configuración del cliente y manejo del nivel de registro
@hiveio/dhive - Cliente blockchain de Hive
@modelcontextprotocol/sdk - SDK de MCP
zod - Validación de esquemas
ISC
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Consulte el archivo CONTRIBUTING.md para obtener pautas de contribución más detalladas.
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.
