모델 컨텍스트 프로토콜을 통해 AI 어시스턴트가 Hive 블록체인과 상호 작용할 수 있도록 하는 MCP 서버입니다.
이 서버는 Claude와 같은 AI 보조원과 Hive 블록체인을 연결하는 브리지 역할을 하며, 이를 통해 AI 모델은 다음과 같은 작업을 수행할 수 있습니다.
계정 정보 및 내역 가져오기
블로그 게시물 및 토론 검색
태그 또는 사용자별로 게시물 가져오기
콘텐츠에 투표하고 게시물을 작성하세요(적절하게 인증된 경우)
HIVE 또는 HBD 토큰을 다른 계정으로 보내기
Hive 키로 메시지 서명 및 확인
암호화된 메시지 보내기 및 받기
Related MCP server: Bankless Onchain MCP Server
create-post - AI가 올바른 형식과 태그를 사용하여 새로운 Hive 게시물을 만들도록 안내하는 구조화된 프롬프트를 생성합니다.
analyze-account - Hive 계정의 통계, 게시 기록 및 활동 패턴을 분석하라는 메시지를 생성합니다.
get_account_info - Hive 블록체인 계정에 대한 자세한 정보를 가져옵니다.
get_post_content - 작성자 및 퍼머링크로 특정 게시물 검색
get_posts_by_tag - 태그 및 카테고리(트렌드, 인기 등)로 게시물을 검색합니다.
get_posts_by_user - 특정 사용자 또는 해당 피드에서 게시물 가져오기
get_account_history - 선택적 작업 필터링을 사용하여 계정의 거래 내역을 가져옵니다.
get_chain_properties - 현재 Hive 블록체인 속성 및 통계 가져오기
get_vesting_delegations - 특정 계정에서 이루어진 위임 위임 목록을 가져옵니다.
vote_on_post - Hive 콘텐츠에 대한 투표(게시 키 필요)
create_post - Hive 블록체인에 새로운 블로그 게시물을 만듭니다(게시 키 필요)
create_comment - 기존 게시물에 댓글을 달거나 댓글에 답변합니다(게시 키 필요)
send_token - HIVE 또는 HBD 암호화폐를 다른 계정으로 보내기(활성 키 필요)
sign_message - Hive 개인 키를 사용하여 메시지에 서명합니다.
verify_signature - Hive 공개 키에 대해 메시지 서명을 확인합니다.
encrypt_message - 특정 Hive 계정에 대한 메시지 암호화
decrypt_message - 특정 Hive 계정에서 암호화된 메시지를 해독합니다.
send_encrypted_message - 토큰 전송을 사용하여 암호화된 메시지를 보냅니다.
get_encrypted_messages - 계정 기록에서 메시지를 검색하고 선택적으로 해독합니다.
MCP Inspector는 서버를 테스트하고 디버깅하기 위한 대화형 인터페이스를 제공합니다.
지엑스피1
인증된 작업(투표, 게시, 토큰 전송)을 활성화하려면 환경 변수를 설정해야 합니다.
export HIVE_USERNAME=your-hive-username
export HIVE_POSTING_KEY=your-hive-posting-private-key # For content operations
export HIVE_ACTIVE_KEY=your-hive-active-private-key # For token transfers
export HIVE_MEMO_KEY=your-hive-memo-private-key # For encrypted messaging보안 참고 : 개인 키를 공유하거나 버전 관리 시스템에 커밋하지 마세요. 환경 변수나 안전한 구성 방식을 사용하세요.
Claude Desktop과 함께 이 서버를 사용하려면:
Claude Desktop이 설치되어 있는지 확인하세요.
Claude 구성 파일을 열거나 만듭니다.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
리눅스: ~/.config/Claude/claude_desktop_config.json
구성에 이 서버를 추가하세요:
{
"mcpServers": {
"hive": {
"command": "npx",
"args": ["-y", "@gluneau/hive-mcp-server"],
"env": {
"HIVE_USERNAME": "your-hive-username",
"HIVE_POSTING_KEY": "your-hive-posting-private-key",
"HIVE_ACTIVE_KEY": "your-hive-active-private-key",
"HIVE_MEMO_KEY": "your-hive-memo-private-key"
}
}
}
}동일한 JSON 구성이 Windsurf( windsurf_config.json ) 및 Cursor(버전 >= 0.47의 경우 ~/.cursor/mcp.json )에 적용됩니다.
이전 버전에서는 설정의 MCP 섹션에서 1줄 명령 형식을 사용해야 했습니다. env HIVE_USERNAME=your-hive-username env HIVE_POSTING_KEY=your-hive-posting-private-key env HIVE_ACTIVE_KEY=your-hive-active-private-key env HIVE_MEMO_KEY=your-hive-memo-private-key npx -y @gluneau/hive-mcp-server
MCP 클라이언트에 연결되면 다음과 같은 질문을 할 수 있습니다.
Hive에서 #photography 태그로 가장 인기 있는 게시물은 무엇인가요?
"사용자 이름 'alice'의 최근 게시물을 보여주세요"
"밥의 계좌 잔액과 세부 정보는 어떻게 되나요?"
"'찰리'의 거래 내역을 받아보세요"
"'dave'의 게시물에 퍼머링크 'my-awesome-post'를 붙여 추천해 주실 수 있나요?"
"Hive에 AI 기술에 대한 새 게시물을 작성하세요"
"사용자 'frank'에게 '도움을 주셔서 감사합니다!'라는 메모와 함께 HIVE 1개를 보내세요."
"내 Hive 게시 키로 이 메시지에 서명하세요: '내 신원 확인'"
"현재 Hive 블록체인의 특징은 무엇입니까?"
"사용자 'grace'가 한 위임을 보여주세요"
"사용자 'alice'에게 이 메시지를 암호화합니다: '이것은 비밀 메시지입니다'"
"'밥'이 보낸 이 메시지를 해독하세요: '#4f3a5b...'"
"'찰리'에게 '내일 만나자'는 내용의 암호화된 메시지를 보내세요."
"암호화된 메시지를 보여주시고 해독해 주세요"
"내가 '데이브'와 주고받은 마지막 암호화된 메시지 10개를 가져와"
get_account_info잔액, 권한, 투표권 및 기타 지표를 포함한 Hive 블록체인 계정에 대한 자세한 정보를 가져옵니다.
매개변수:
username : 정보를 가져올 Hive 사용자 이름
get_post_content작성자와 퍼머링크로 식별된 특정 Hive 블로그 게시물을 검색합니다.
매개변수:
author : 게시물 작성자
permlink : 게시물의 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 : 하이브 사용자 이름
limit : 반환할 작업 수
operation_filter : 필터링할 작업 유형의 선택적 목록
get_chain_properties현재 Hive 블록체인 속성과 통계를 가져옵니다.
매개변수: 없음
get_vesting_delegations특정 Hive 계정에서 이루어진 위임된 권한 목록을 가져옵니다.
매개변수:
username : 위임을 받을 Hive 계정
limit : 검색할 최대 위임 수
from : 페이지 매김을 위한 선택적인 시작 계정
vote_on_post구성된 Hive 계정을 사용하여 Hive 게시물에 투표하세요(추천 또는 비추천).
매개변수:
author : 투표할 게시물의 작성자
permlink : 투표할 게시물의 Permlink
weight : 투표 가중치 -10000(100% 다운보트)에서 10000(100% 업보트)까지
create_post구성된 계정을 사용하여 Hive 블록체인에 새로운 블로그 게시물을 만듭니다.
매개변수:
title : 블로그 게시물의 제목
body : 블로그 게시물의 내용(마크다운 지원)
tags : 게시물에 대한 태그
보상, 수혜자 등에 대한 다양한 선택 매개변수
create_comment기존 Hive 게시물에 댓글을 작성하거나 다른 댓글에 답변합니다.
매개변수:
parent_author : 답글을 달고 있는 게시물 작성자 또는 댓글의 사용자 이름
parent_permlink : 답글을 달고 있는 게시물이나 댓글의 영구 링크
body : 댓글 내용 (마크다운 지원)
보상, 수혜자 등에 대한 다양한 선택 매개변수
send_token구성된 계정을 사용하여 HIVE 또는 HBD 토큰을 다른 Hive 계정으로 보냅니다.
매개변수:
to : 수신자 Hive 사용자 이름
amount : 보낼 토큰의 양
currency : 보낼 통화(HIVE 또는 HBD)
memo : 거래에 포함할 선택적 메모
sign_message환경 변수의 Hive 개인 키를 사용하여 메시지에 서명합니다.
매개변수:
message : 서명할 메시지
key_type : 사용할 키 유형(게시, 활성 또는 메모)
verify_signatureHive 공개 키에 대한 디지털 서명을 확인합니다.
매개변수:
message_hash : 16진수 형식의 메시지의 SHA-256 해시
signature : 검증할 서명 문자열
public_key : 검증할 공개 키
encrypt_message메모 암호화를 사용하여 특정 Hive 계정에 대한 메시지를 암호화합니다.
매개변수:
message : 암호화할 메시지
recipient : 수신자의 Hive 사용자 이름
decrypt_message특정 Hive 계정에서 받은 암호화된 메시지를 해독합니다.
매개변수:
encrypted_message : 암호화된 메시지(#으로 시작)
sender : 발신자의 Hive 사용자 이름
send_encrypted_message소액 토큰 전송을 사용하여 Hive 계정으로 암호화된 메시지를 보냅니다.
매개변수:
message : 암호화하여 보낼 메시지
recipient : 수신자의 Hive 사용자 이름
amount : 보낼 HIVE의 양(최소 0.001, 기본값: 0.001)
get_encrypted_messages선택적으로 복호화하여 계정 기록에서 암호화된 메시지를 검색합니다.
매개변수:
username : 암호화된 메시지를 가져올 Hive 사용자 이름
limit : 검색할 최대 메시지 수(기본값: 20)
decrypt : 메시지의 암호 해독을 시도할지 여부(기본값: false)
src/index.ts - 메인 서버 구현
src/tools/ - 모든 도구 구현
src/schemas/ - 도구 매개변수에 대한 Zod 스키마
src/utils/ - Hive 블록체인과 상호 작용하기 위한 유틸리티 함수
src/config/ - 클라이언트 구성 및 로그 수준 처리
@hiveio/dhive - Hive 블록체인 클라이언트
@modelcontextprotocol/sdk - MCP SDK
zod - 스키마 검증
아이에스씨
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
더 자세한 기여 지침은 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.
