Production MCP server giving AI agents metered access to live Hedera blockchain data. Query token prices, screen identities, monitor governance, write tamper-evident HCS compliance records, and analyze smart contracts — all paid in HBAR micropayments per call.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 25 of 25 tools scored. Lowest: 3.1/5.
Each tool targets a distinct resource and action (e.g., contract read vs. contract call vs. contract analyze; hcs monitor vs. hcs query vs. hcs understand). Even within closely related groups, descriptions clearly differentiate the specific purpose, so an agent is unlikely to select the wrong tool.
Most tools follow a domain_action pattern (e.g., contract_analyze, token_monitor, hcs_verify_record), but some are verb_noun (get_terms, confirm_terms) and a few are noun_noun (account_info, token_price, fixatum_score). While not perfectly uniform, the prefixes make the intended domain clear and the overall structure is readable.
With 25 tools, the server is on the heavy end of the typical MCP scope. While each tool serves a specific niche across multiple Hedera domains (contracts, HCS, tokens, identity, governance, Fixatum), the sheer number could increase selection complexity, but it remains within the borderline range rather than being excessive.
The server covers a broad range of read/analyze operations across major Hedera areas, plus essential write/verification capabilities (hcs_write_record, hcs_verify_record) and an onboarding flow (get_terms, confirm_terms). Minor gaps exist, such as no token transfer history or unregister/update for Fixatum, but the core analytical purpose is well covered.
account_infoAPlatform wallet, live pricing for all 23 tools in HBAR/USD, and your balance. FREE. Call first to onboard: send HBAR to platform wallet, your Hedera account ID becomes your API key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional. Your Hedera account ID (e.g. 0.0.456789) or API key. If provided, your current balance is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, non-destructive operation. The description adds valuable behavioral context: it is FREE, requires onboarding by sending HBAR to a platform wallet, and explains how the Hedera account ID becomes an API key. This goes beyond the annotations without contradicting them.
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 that packs multiple facts (wallet, pricing, balance, free, onboarding) without rambling. It is front-loaded with purpose and does not waste words, though the sentence is slightly dense.
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 tool with one optional parameter and no output schema, the description covers what it does, how to get started, and the meaning of the parameter. It lacks explicit return format details, but this is not a major gap given the tool's simplicity.
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 already fully documents the optional api_key parameter with type, example, and effect (returns balance). Description reiterates the onboarding/key relationship but adds no syntax or format details beyond schema. Since schema coverage is 100%, baseline 3 applies.
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 identifies the tool as providing platform wallet info, live pricing for all 23 tools, and user balance. It has a specific verb (though implicit) and resource. It does not explicitly contrast with sibling tools like token_price, so it slightly lacks differentiation.
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 includes an onboarding instruction ('Call first to onboard') and a hint about the api_key role, which implies usage context. However, it does not clearly state when to use this tool versus alternatives like token_price or balance-specific tools, and offers no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_termsAAccept Terms of Service. Required before any paid tool executes. FREE.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your Hedera account ID / API key (e.g. 0.0.456789) | |
| confirmed | Yes | Must be true. Passing false is a no-op. | |
| terms_version | Yes | The terms version you are accepting — must match the current version returned by get_terms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the description doesn't need to restate mutability. It adds that the operation is FREE and a prerequisite, but doesn't elaborate on what 'destructive' means or side effects of acceptance; with destructiveHint true, more clarification would be valuable.
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?
Two short sentences, front-loaded with the core action. 'FREE' is perhaps extraneous but conveys cost context; overall very concise with no waste.
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 prerequisite tool, the description plus rich schema is nearly complete. It covers when to use, required parameters, and validation rules. Missing only return values/no-op behavior, but those are minor for this tool.
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 covers 100% of parameters with detailed descriptions (api_key format, confirmed must be true, terms_version must match get_terms). Description adds no parameter-level detail beyond the schema, so baseline 3 applies.
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 uses specific verb 'Accept' with direct object 'Terms of Service', clearly identifying the tool's function. It also adds differentiating context ('Required before any paid tool executes') that distinguishes it from sibling tools like get_terms.
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?
Explicitly states the tool is required before any paid tool executes, giving clear invocation context. It doesn't name alternatives or exclusions, but the prerequisite framing is strong enough; get_terms is referenced indirectly via schema for version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_analyzeAHedera contract deep analysis: activity, caller distribution, gas, risk, classification. 1.5 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| contract_id | Yes | Hedera contract ID to analyze (e.g. 0.0.123456) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only operation (readOnlyHint=true, destructiveHint=false). The description adds the cost '1.5 HBAR' and the scope of analysis, which is useful beyond annotations, but does not disclose output format, latency, or other behavioral traits.
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 that front-loads the purpose and lists key features, including the cost, with no unnecessary 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?
For a complex analysis tool without an output schema, the description covers the main purpose but omits return value details, prerequisites, or any additional context needed to fully understand the analysis 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?
The input schema has 100% parameter description coverage, so the baseline is 3. The description does not add any parameter-specific meaning 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 performs 'Hedera contract deep analysis' and enumerates specific aspects ('activity, caller distribution, gas, risk, classification'), making it distinct from sibling tools like contract_read or token_analyze.
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 via 'deep analysis' and the listed analytical dimensions, but it provides no explicit when-to-use/when-not-to-use guidance or references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_callARead-only call to a Hedera contract function. No tx submitted. 1.0 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| abi_hint | No | Optional full function signature for precise ABI encoding e.g. 'balanceOf(address)' or 'getReserves()' | |
| contract_id | Yes | Hedera contract ID (e.g. 0.0.123456) or EVM address (0x...) | |
| return_types | No | Optional ABI return types for precise decoding e.g. ['uint112','uint112','uint32'] for getReserves, ['address'] for owner | |
| function_name | Yes | Contract function name to call (e.g. balanceOf, totalSupply, name) | |
| function_params | No | Optional array of parameter values to pass to the function |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by stating 'No tx submitted' and '1.0 HBAR' (likely a cost or fee), which goes beyond the annotations and clarifies the tool's behavior and implications.
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 extremely concise with three short sentences, front-loading the primary purpose. Every word earns its place, with no unnecessary elaboration or repetition.
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 full schema coverage and annotations, the description is adequate for a straightforward read-only call. It mentions cost and safety, but does not explicitly describe the return value or when optional ABI hints are needed. Still, the schema documents parameters and the purpose is clear, so it is reasonably complete.
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% for all 6 parameters, so the baseline is 3. The description adds no additional parameter-level details beyond what the schema already provides, but the schema descriptions are sufficiently explicit.
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 a specific verb 'call' on a 'Hedera contract function' and specifies it is 'Read-only' with 'No tx submitted', effectively distinguishing it from write operations. While a sibling tool 'contract_read' exists, the read-only framing helps differentiate the purpose.
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 read-only contract calls but provides no explicit guidance on when to use this tool versus alternatives like contract_read or contract_analyze. It lacks exclusions or recommendations, leaving the usage context inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_readAHedera contract state: info, bytecode size, recent activity, storage. No tx executed. 0.2 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| contract_id | Yes | Hedera contract ID (e.g. 0.0.123456) or EVM address (0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. It adds cost information (0.2 HBAR) and specifies the data categories returned, which are beyond the annotations. No contradiction found.
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 line, front-loading the tool's purpose, key data types, and the critical exclusion of execution. Every phrase adds value—the cost and state aspects are all relevant. 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?
For a two-parameter read-only tool with complete schema and clear annotations, the description provides enough context: purpose, what data is returned, cost, and a key usage exclusion. It doesn't detail return structure, but given no output schema, the description's coverage is adequate.
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 both parameters with thorough descriptions (contract_id and api_key). The description doesn't add parameter syntax details, but with 100% schema coverage, the baseline of 3 is appropriate. The description's mention of 'state' plus the schema is sufficient.
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 reads Hedera contract state, listing specific aspects (info, bytecode size, recent activity, storage). It explicitly says 'No tx executed', distinguishing it from contract_call and other executory tools. This is a specific verb-like resource scope with sibling differentiation.
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 statement 'No tx executed' provides a clear exclusion, implying this tool is for read-only state inspection and not for executing transactions on the contract. While it doesn't explicitly name contract_call as the alternative, the contrast is clear and sufficient for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fixatum_fleet_inboxARead unresolved flagged items from the Fixatum agent inbox. Returns items posted by Scout, Narrator, or other agents requiring Midas attention. Free. Only callable by Midas (0.0.10435510).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaToolbox API key. Must be Midas account (0.0.10435510). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the access restriction (only callable by Midas account), the fact that it is free, and the types of items returned, all of which are valuable behavioral context beyond the annotations.
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 succinct, with the main purpose in the first sentence and only essential additional information in the following sentences. 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?
The tool is simple with one parameter and read-only behavior. The description explains what it does, who can call it, and what it returns, which is sufficient for a basic read tool, though an output format would improve completeness.
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?
With 100% schema description coverage, the api_key parameter is already fully documented, including the Midas account requirement. The description reinforces this but does not add meaningful new detail about parameter semantics.
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 identifies the tool as a read operation for the Fixatum agent inbox, specifying the verb 'Read' and the resource. It distinguishes itself from sibling tools like fixatum_fleet_status and fixatum_status by focusing on inbox items rather than fleet or system status.
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 clear context that this tool is for reading unresolved flagged items from agents and is restricted to the Midas account. However, it does not explicitly mention when to prefer this over alternative tools, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fixatum_fleet_statusARead all agent statuses and inbox count from the Fixatum agent communication layer. Returns latest report from each agent (VisionForge, Scout, Narrator) plus unresolved inbox item count. Free. Only callable by Midas (0.0.10435510).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaToolbox API key. Must be Midas account (0.0.10435510). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive, and the description adds valuable context: the authentication requirement (Midas account), cost (Free), and return structure (latest report per agent plus inbox count). This goes beyond the annotations without contradicting them.
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 concise (three short sentences) and front-loaded with the primary action. Each sentence contributes distinct information: function, return details, and access/cost, with zero 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?
For a simple read-only tool with one parameter, the description covers purpose, return content, and access restrictions. It lacks detailed output format or error behavior, but these are not critical given the simplicity and existing schema annotations.
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% for the single api_key parameter, so the parameter is fully documented there. The description adds no extra parameter semantics, aligning with the baseline for full schema coverage.
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 reads all agent statuses and inbox count, with specific verbs and resource ('Read all agent statuses and inbox count from the Fixatum agent communication layer'). It also names the agents (VisionForge, Scout, Narrator) and distinguishes itself from siblings like fixatum_fleet_inbox by covering both statuses and inbox count.
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?
Usage context is implied: this is for retrieving all agent statuses and inbox count at once. However, no explicit alternatives or when-not-to-use guidance is given. The access restriction ('Only callable by Midas') is a constraint, not an alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fixatum_registerAInspectRegister this agent with Fixatum to get a permanent W3C-compliant DID (did:hedera:mainnet:z...) anchored to Hedera HCS and a live KYA trust score. Costs 100 HBAR. Requires a dedicated Ed25519 key pair — NOT your Hedera account key. Call with hedera_account_id only to get full prerequisites and key generation instructions. Free prerequisite check, no charge until registration proceeds.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaToolbox API key (Hedera account ID). | |
| hedera_account_id | Yes | Your Hedera account ID (e.g. 0.0.123456) — this becomes part of your DID. | |
| ed25519_public_key | No | Your Ed25519 public key encoded as base58btc multibase (starts with z, 40–50 chars). NOT your Hedera ECDSA key. Omit to get prerequisites and key generation instructions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses important behavioral traits: the cost, the need for a dedicated key pair, and that the prerequisite check is free with no charge until registration proceeds. It does not describe failure modes or full return behavior, but it is substantially transparent for a mutation 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 three sentences, front-loaded with the core purpose, and every sentence earns its place: outcome, cost/prerequisite, and usage instruction. No redundant or filler 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?
For a registration tool with no output schema, the description covers the essential context: purpose, cost, key requirements, and an initial invocation pattern. It does not describe the exact response shape or error handling, but given the tool's complexity, it is adequately complete.
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 schema provides 100% coverage with descriptions for all three parameters, giving a baseline of 3. The description adds meaning beyond the schema by clarifying that hedera_account_id becomes part of the DID and that ed25519_public_key is NOT the Hedera ECDSA key, and that omitting it triggers prerequisite instructions.
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 purpose with a specific verb ('Register') and resource ('with Fixatum to get a permanent W3C-compliant DID and a live KYA trust score'). It distinguishes from sibling tools like fixatum_status or fixatum_score by focusing on the registration action and its outcomes.
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 gives clear context: prerequisites (dedicated Ed25519 key pair, not your Hedera account key), cost (100 HBAR), and a concrete usage instruction ('Call with hedera_account_id only to get full prerequisites and key generation instructions'). It doesn't explicitly name alternatives or when not to use, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fixatum_scoreAQuery a live Fixatum KYA trust score for any registered agent. Returns 0-100 score, grade (A-F), and component breakdown (provenance, account age, screening, anomaly signal). Free. Pass a Hedera account ID or full did:hedera DID.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaToolbox API key (Hedera account ID). | |
| did_or_account_id | Yes | Full Fixatum DID (did:hedera:mainnet:z...) or Hedera account ID (0.0.XXXXXX). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds value by detailing the response structure (0-100 score, A-F grade, component breakdown) and noting it is free, which goes beyond annotation coverage. No contradictions with annotations.
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 two sentences with no filler. The first sentence states the action and scope, and the second efficiently communicates the output, cost, and accepted input formats. Every clause 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?
For a simple read-only query tool with two parameters, the description covers the purpose, input requirements, and output structure. It could also mention edge cases like behavior for unregistered agents or invalid DIDs, but the provided context is sufficient for the tool's complexity.
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 both parameters (api_key and did_or_account_id) well-described in the schema itself. The description reiterates that you can pass a Hedera account ID or full did:hedera DID, but this adds no new meaning beyond what the schema already provides, so a 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?
The description uses 'Query' as a specific verb and clearly identifies the resource as a live Fixatum KYA trust score for any registered agent. It also lists the return values (score, grade, component breakdown), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like fixatum_status, but the resource name is distinctive enough.
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 when to use this tool: when you need a live KYA trust score for a Hedera agent. It mentions 'for any registered agent' and includes 'Free' as a practical consideration. However, it provides no explicit when-not-to-use guidance or alternatives among the sibling tools, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fixatum_statusACheck Fixatum registration status for a Hedera account. Returns DID if registered, live score, and whether provenance is actively building. Free. Use before fixatum_register to check if already registered.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaToolbox API key (Hedera account ID). | |
| hedera_account_id | Yes | Hedera account ID to check (e.g. 0.0.123456). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only safe behavior (readOnlyHint=true, destructiveHint=false), and the description adds valuable context: the tool is free, returns specific fields (DID, live score, provenance building status), and implies special behavior if not registered. This goes beyond the annotations without contradiction.
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 three sentences, front-loaded with the core purpose. Each sentence adds value: what it does, what it returns, and when to use it. The word 'Free.' is slightly redundant but does not detract. No fluff or unnecessary detail.
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?
Without an output schema, the description compensates by listing the main return fields (DID, live score, provenance status). It also gives usage context and pricing. It does not specify the response when the account is not registered, but the simple nature of the tool (2 params, read-only) makes this a minor gap. Overall, it is sufficiently complete for an agent to invoke correctly.
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 fully documents both parameters with clear descriptions (api_key, hedera_account_id), achieving 100% schema coverage. The description adds minimal extra parameter meaning beyond aligning them with the tool's purpose. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 function: 'Check Fixatum registration status for a Hedera account.' It uses a specific verb ('check') and identifies the resource (Fixatum registration) and target (Hedera account). It also distinguishes itself from the sibling fixatum_register by indicating this is the pre-check 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?
The description explicitly advises 'Use before fixatum_register to check if already registered,' providing a clear when-to-use scenario. It also lists the returned data (DID, live score, provenance status) which helps the agent decide if this tool fits. It does not explicitly state when not to use it or name alternatives, but the primary use case is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_termsAMachine-readable Terms of Service. FREE. Call before any paid tool, then confirm_terms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: the tool is free, returns machine-readable data, and is a mandatory precursor. These are behavioral traits not visible in annotations, though it doesn't detail return format or error handling.
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 extremely concise, delivering all essential information in two short sentences without any wasted words. Key facts are front-loaded.
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 zero-parameter read-only tool with annotations covering safety, the description fully covers purpose, usage context, and the next step. No gaps remain for an agent to select and invoke it correctly.
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 tool has zero parameters, so the description doesn't need to explain any. The baseline of 4 is appropriate because there is nothing to clarify 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 identifies the tool as providing machine-readable Terms of Service and implies the retrieval action. It distinguishes itself from siblings by explicitly positioning it as a prerequisite step before paid tools, with confirm_terms as a follow-up.
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?
Explicitly instructs the agent to call this tool before any paid tool and then use confirm_terms. This provides clear when-to-use guidance and a sequence, leaving no ambiguity about its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
governance_analyzeAGovernance proposal analysis: voter sentiment, participation, concentration, outcome prediction. 1.0 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| token_id | Yes | Hedera token ID the proposal belongs to | |
| topic_id | No | HCS topic ID where proposal votes are recorded | |
| proposal_id | Yes | Proposal ID or HCS sequence number to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool costs '1.0 HBAR,' which adds behavioral context beyond the readOnlyHint=true annotation. It also implies a read-only analytical operation consistent with the annotations. However, it does not describe return format or other behavioral details, but annotations already cover safety, so the extra cost disclosure earns a high score.
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 is front-loaded with the tool's purpose and ends with the cost. Every word adds value; there is no filler or 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?
Given annotations declare the tool read-only and non-destructive, and the description explains the analysis focus and cost, it is reasonably complete for a simple analysis tool. It lacks output format details, but with no output schema and a straightforward function, this is acceptable. The sibling ecosystem (e.g., governance_monitor) suggests context, but the description stands alone well.
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 four parameters with descriptions, so schema_description_coverage is 100%. The description does not elaborate on parameter usage or add meaning beyond the schema. It lists analysis dimensions but does not tie them to specific parameters. 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?
The description clearly states the tool's function as 'Governance proposal analysis' and enumerates specific analytical dimensions (voter sentiment, participation, concentration, outcome prediction), which distinguishes it from siblings like governance_monitor. However, it lacks an explicit verb, using a noun phrase instead, which slightly reduces clarity.
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. It does not mention governance_monitor or any other tool, nor does it specify optimal use cases or prerequisites. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
governance_monitorAActive governance proposals for a Hedera token or DAO: open proposals, deadlines, vote tallies. 0.2 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| token_id | Yes | Hedera token ID to monitor governance for (e.g. 0.0.123456) | |
| topic_id | No | Optional HCS topic ID used for governance messages |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description carries less burden. It adds useful behavioral context by noting the 0.2 HBAR cost, which is not present in annotations. It does not contradict annotations and gives additional practical information for an agent deciding to invoke the 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 two sentences, front-loaded with the core purpose. It efficiently conveys the resource, the data provided, and the cost without redundancy. Every phrase adds value, and there is no filler.
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 read-only listing tool with three parameters and no output schema, the description covers the essential functionality and return content (open proposals, deadlines, vote tallies) plus cost. It does not explain edge cases or how optional parameters affect results, but the schema handles parameter definitions. Overall it is reasonably complete for the tool's complexity.
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 already provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description does not add any extra meaning to the parameters beyond what the schema already states, such as usage nuances or default behaviors. It simply mentions 'token or DAO' without linking to specific 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 function: retrieving active governance proposals for a Hedera token or DAO, with specific data points (open proposals, deadlines, vote tallies). It uses a specific resource and content list, though it does not explicitly distinguish itself from sibling tools like governance_analyze or hcs_monitor.
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, nor does it mention exclusions or prerequisites. It only implies usage context from its purpose, but lacks explicit direction that would help an agent choose between this and overlapping sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcs_audit_trailBFull chronological audit trail for an entity from Hedera HCS. 2.0 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records to retrieve (default 50) | |
| api_key | Yes | Your HederaIntel API key | |
| topic_id | No | HCS topic ID to query. Defaults to the HederaIntel platform topic. | |
| entity_id | Yes | Entity ID to retrieve audit trail for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the 2.0 HBAR cost, which is useful behavioral context beyond annotations, but does not mention other behaviors like pagination 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 very brief and front-loaded with the core action, followed by the cost. No wasted words, though it could be more informative. It earns a high score for conciseness.
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 tool has four parameters and no output schema, the description is incomplete. It doesn't explain when to use this tool, what the response contains, or any limitations. The minimal description may leave the agent without enough context to select it correctly among siblings.
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 does not add parameter-level details beyond mentioning 'entity', but the baseline of 3 applies because the schema handles parameter documentation.
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 full chronological audit trail for an entity from Hedera HCS, which is a specific verb+resource. It is distinguishable from sibling HCS tools by focusing on 'audit trail', though it does not explicitly name alternatives.
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 gives no guidance on when to use this tool versus alternatives like hcs_query or hcs_verify_record. It only states what it does, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcs_monitorBHCS topic status: message count, creation time, memo. Defaults to platform topic. 0.1 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| topic_id | No | Hedera topic ID (e.g. 0.0.8026796). Defaults to the HederaIntel platform topic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context such as the default topic and the 0.1 HBAR cost, plus the specific output fields. However, it does not disclose error behavior, whether the fee is per call, or any details about pagination or data freshness. This adds some value beyond annotations but not substantial depth.
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 extremely concise: one sentence plus two short fragments, 13 words total. Every phrase adds information (purpose, defaults, cost). It is front-loaded with the core function and contains no fluff. This is an excellent example of minimal yet informative structure.
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 read-only monitor with a small schema and clear annotations, the description is largely complete. It names the output fields (message count, creation time, memo), communicates the default topic, and notes the cost. The absence of an output schema makes the explicit return-field list helpful. Minor gaps like the meaning of '0.1 HBAR' and any error handling keep it from a perfect score.
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% for both parameters (api_key and topic_id). The description adds a meaningful default behavior for topic_id ('Defaults to platform topic') and mentions the fee, but does not significantly expand on parameter semantics beyond what the schema already provides. The baseline of 3 applies because the schema carries the parameter documentation effectively.
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 identifies the tool's function as retrieving HCS topic status including message count, creation time, and memo. It is specific about the resource (HCS topic) and the output fields, but lacks an explicit verb like 'get' or 'retrieve'. While it mentions a default topic, it does not explicitly contrast with sibling tools such as hcs_query or hcs_understand, so it slightly misses on differentiation.
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 minimal context about when to use this tool. It states the default to the platform topic and the cost (0.1 HBAR), but offers no guidance on when to choose this over alternatives like hcs_query or hcs_verify_record. No exclusions, prerequisites, or explicit use-case scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcs_queryANatural language query on an HCS topic. Returns ranked messages and summary. 0.1 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max messages to retrieve (default 50) | |
| query | Yes | Natural language question about the topic | |
| api_key | Yes | Your HederaIntel API key | |
| topic_id | No | Hedera topic ID (e.g. 0.0.8026796). Defaults to the HederaIntel platform topic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral traits: that it returns 'ranked messages and summary' and costs '0.1 HBAR' – a financial side effect not visible in annotations. This goes beyond the baseline, though it omits details like rate limits or failure modes.
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 two sentences with zero filler. It front-loads the core action, specifies the output, and notes the cost. Every word adds value, making it highly concise and well-structured.
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 read-only query tool with full schema coverage and annotations, the description adequately covers the return type and cost. It does not mention the default topic or when to choose this over sister tools, but given the low complexity and existing schema/annotation context, it is reasonably complete. A small gap is the lack of differentiation from similar hcs tools.
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% for all four parameters, so the schema fully documents each parameter. The description mentions 'natural language query' which aligns with the query param but does not add additional parameter-level meaning beyond what the schema already provides. 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?
The description clearly states the tool performs a 'natural language query on an HCS topic' and returns 'ranked messages and summary' – a specific verb and resource with output scope. However, it does not explicitly differentiate from siblings like hcs_understand, hcs_monitor, or hcs_audit_trail, so it lacks explicit sibling distinction.
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?
There is no guidance on when to use this tool versus alternatives. The description only explains what the tool does without mentioning any prerequisites, exclusions, or preferred contexts. Sibling tools exist for monitoring, understanding, and auditing, but no comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcs_understandADeep HCS topic analysis: anomaly detection, trends, entity extraction, risk. 1.0 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| topic_id | No | Hedera topic ID. Defaults to the HederaIntel platform topic. | |
| analysis_type | Yes | Type of analysis to perform | |
| lookback_days | No | Days of history to analyze (default 7, max 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable cost information ('1.0 HBAR') and the scope of analysis beyond what annotations provide. Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them, giving good transparency for a read-only analysis 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, front-loaded sentence that immediately states the tool's purpose and lists key analysis types. There is no unnecessary verbosity; every word contributes to understanding the tool's function.
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 description effectively conveys the core purpose and analysis categories, but it lacks detail on expected outputs (no output schema exists) and does not provide guidance on selecting this tool versus closely related siblings. For a moderately complex tool with a parameter enum, this is adequate but not comprehensive.
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 provides descriptions for all parameters (100% coverage), so the baseline is 3. The description does not add extra parameter-specific details beyond echoing the analysis_type options, and it does not elaborate on topic_id or lookback_days, which are already documented in 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 indicates the tool performs deep HCS topic analysis and lists specific analysis types (anomaly detection, trends, entity extraction, risk). It distinguishes itself from sibling tools by emphasizing 'deep' analysis, though it lacks an explicit verb like 'analyze' and relies on the title for clarity.
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 scenarios by enumerating analysis types, suggesting when one might need deep analysis. However, it does not explicitly state when to use this tool over alternatives like hcs_query or hcs_monitor, nor does it provide exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcs_verify_recordAVerify a compliance record on Hedera HCS has not been tampered. 1.0 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| topic_id | No | HCS topic ID where the record was written. Defaults to the HederaIntel platform topic. | |
| record_id | Yes | Record ID returned when the record was written |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations by disclosing the 1.0 HBAR cost, which is a significant operational detail. It also clarifies the purpose as a tamper check rather than a general query, adding depth to the 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?
The description is extremely concise: two short sentences. The first sentence front-loads the core purpose, and the second provides essential cost information. Every word earns its place, with no redundancy or filler.
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 verification tool with three parameters and no output schema, the description is largely complete. It states the purpose, cost, and the fact that it checks tampering. It could mention what the output looks like (e.g., boolean or report), but the absence of an output schema reduces the burden. Overall, it provides enough context for an agent to understand and invoke the tool correctly.
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 already provides 100% coverage of parameter descriptions for api_key, topic_id, and record_id, so the baseline is 3. The description does not add further parameter-specific semantics, but it does refer to 'compliance record' which loosely ties to record_id. This is adequate but not exceptional.
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 uses a specific verb ('Verify') and a clear resource ('compliance record on Hedera HCS') with a defined outcome ('has not been tampered'). This clearly distinguishes it from sibling tools like hcs_query or hcs_audit_trail, which are about querying or auditing rather than integrity verification.
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 clearly implies when to use the tool: when you need to confirm that a specific compliance record on Hedera HCS has not been tampered. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it over related tools like hcs_query or hcs_monitor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcs_write_recordAWrite a tamper-evident record to any open HCS topic on Hedera. Use this to write entries to your agent's own topic for continuity, memory, or history. topic_id is required — pass your agent topic ID. Returns record ID and tx proof. 0.1 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The compliance data to record (any JSON object) | |
| api_key | Yes | Your HederaIntel API key | |
| topic_id | Yes | HCS topic ID to write the record to. Must be an open topic you own or have access to. | |
| entity_id | Yes | ID of the entity this record relates to | |
| record_type | Yes | Type of compliance record (e.g. transaction, approval, audit_event) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds valuable context: tamper-evidence, return of record ID and tx proof, and the 0.1 HBAR cost. It does not contradict annotations and gives extra behavioral insight.
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 two sentences, front-loaded with purpose and usage, then a required parameter note, return values, and cost. No filler or 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?
Given no output schema, the description appropriately mentions return values (record ID and tx proof) and the cost. It could elaborate on immutable/permanent effects or error cases, but the schema covers access requirements, making it sufficiently complete.
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 baseline is 3. The description adds value by highlighting topic_id as required and suggesting to 'pass your agent topic ID', and by implying the data field contains compliance data, slightly beyond schema descriptions.
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 states a specific verb and resource: 'Write a tamper-evident record to any open HCS topic on Hedera.' It clearly distinguishes this write tool from read/verify siblings like hcs_query and hcs_verify_record.
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?
It provides clear usage context: 'Use this to write entries to your agent's own topic for continuity, memory, or history.' It does not explicitly mention alternatives or when not to use, but the context is sufficient among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identity_check_sanctionsASanctions and risk screening for a Hedera account: tx patterns, counterparty risk. 1.0 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| account_id | Yes | Hedera account ID (e.g. 0.0.123456) or EVM address (0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is known. The description adds useful context about the focus (tx patterns, counterparty risk) and the cost (1.0 HBAR), complementing the annotations.
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 that communicates the core purpose and the fee with no unnecessary words. Every piece of information 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?
For a read-only screening tool with two well-documented parameters and no output schema, the description covers the purpose and cost clearly. It does not specify the exact return format, but the lack of an output schema and the simplicity of the tool make the description adequate.
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 provides full descriptions for both parameters (api_key and account_id) with 100% coverage, so the description is not required to add parameter details. It does connect account_id to the account under screening but adds no further parameter-level semantics.
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 uses the specific verb phrase 'Sanctions and risk screening' and identifies the resource 'Hedera account', then elaborates with 'tx patterns, counterparty risk'. This clearly distinguishes the tool from siblings like identity_verify_kyc or account_info.
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 sets a clear context: it is for sanctions/risk screening of Hedera accounts, which implies when to use it. It does not explicitly mention alternatives or exclusions, but the use case is evident from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identity_resolveAResolve Hedera account ID or EVM address to on-chain profile: age, tokens, tx history. 0.2 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| account_id | Yes | Hedera account ID (e.g. 0.0.123456) or EVM address (e.g. 0x1234...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the important behavioral detail that this operation costs 0.2 HBAR. It also discloses the output fields, adding value beyond annotations.
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 that front-loads the core purpose and includes the cost. Every word contributes meaning.
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 two-parameter read-only tool, the description covers purpose, input, return fields, and cost. It lacks detail on failure modes or pagination, but these are less critical given the tool's simplicity.
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 both parameters clearly described (account_id supports Hedera ID or EVM address, api_key). The description adds nothing beyond what the schema already explains, 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?
The description uses a specific verb 'Resolve' and clearly identifies the resource (Hedera account ID or EVM address) and the output (on-chain profile with age, tokens, tx history). It distinguishes from siblings by focusing on profile resolution rather than sanctions checks or general account info.
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 when to use the tool: when you need a comprehensive on-chain profile for an account. It provides clear context but does not explicitly reference alternatives or exclusions, earning a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identity_verify_kycBKYC status of a Hedera account for one or more tokens. 0.5 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| token_id | No | Optional token ID to check KYC status for a specific token | |
| account_id | Yes | Hedera account ID (e.g. 0.0.123456) or EVM address (0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive; the description adds the important behavioral detail of a 0.5 HBAR cost and the flexibility of checking one or more tokens. It does not mention potential return format or rate limits, but with annotations covering safety, the additional cost disclosure is valuable.
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 two short sentences with no filler; every word contributes either purpose or cost. It is efficiently front-loaded.
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 paid read tool with no output schema, the description lacks return-value expectations (e.g., what a KYC status result looks like) and how the 0.5 HBAR fee is charged or from which account. It also does not state behavior when token_id is omitted (all tokens vs. generic status), leaving meaningful 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% (all three parameters described), so the description need not repeat parameter details. It adds the clarifying phrase 'one or more tokens' which aligns with token_id being optional, but does not enrich parameter semantics beyond that.
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 states 'KYC status of a Hedera account for one or more tokens' with title 'Verify KYC Status', clearly indicating a read-only check. It specifies the resource (Hedera account) and scope (one or more tokens), but does not explicitly contrast with sibling identity_check_sanctions or identity_resolve.
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 given on when to use this tool versus alternatives like identity_check_sanctions or identity_resolve. The context is implied by the KYC naming, but there are no explicit use-case conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_analyzeAHedera token deep analysis: holder distribution, velocity, liquidity, risk score. 0.6 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| token_id | Yes | Hedera token ID to analyze (e.g. 0.0.123456) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context by mentioning the cost (0.6 HBAR) and specifying the analysis dimensions, which goes beyond the annotations. However, it does not disclose other behavioral details such as response format or rate limits, so it does not fully reach 5.
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 tool's purpose and lists key outputs. It includes the cost in a compact, useful way, with no redundant or filler content. 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?
The tool has a simple signature (2 params, no nested objects) and no output schema. The description compensates by listing the analysis dimensions, which imply the return content. It also includes cost information. Missing is a bit more detail on what the response structure looks like or any error handling, but given the modest complexity, it is reasonably complete.
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 provides 100% coverage of the parameters, describing both token_id and api_key. The description does not add any additional parameter-level semantics beyond what the schema already provides, so the 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 identifies the resource (Hedera token) and the action (deep analysis), listing concrete outputs like holder distribution, velocity, liquidity, and risk score. It lacks an explicit verb such as 'analyzes' or 'returns', which prevents a perfect score, but it is specific enough to distinguish from sibling tools like token_price or token_monitor.
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 when to use this tool based on the listed analytics, but it does not explicitly state when to use it versus alternatives. There is no mention of exclusions or comparisons with sibling tools like token_monitor or token_price, leaving the usage context somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_monitorBHedera token whale movements and unusual transfer patterns. 0.2 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent transactions to return (default 25, max 100) | |
| api_key | Yes | Your HederaIntel API key | |
| token_id | Yes | Hedera token ID to monitor (e.g. 0.0.123456) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only safe behavior (readOnlyHint=true, destructiveHint=false). The description adds that the tool focuses on whale movements and unusual transfers, and introduces a cost of 0.2 HBAR, which is valuable beyond the annotations. However, it does not disclose response format, pagination, or any failure modes.
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 one short sentence, front-loaded with the core function and a cost note. It is a model of brevity with no filler or 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?
For a simple read-only API with three fully documented parameters and no output schema, the description provides the essential purpose but stops short of explaining what the caller receives or any response structure. Since no output schema exists, the description should compensate by outlining return expectations, but it only gives a high-level monitoring concept.
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 baseline is 3. The description does not elaborate on token_id, api_key, or limit beyond what the schema already provides. The '0.2 HBAR' note is unrelated to parameter semantics.
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 identifies the tool's focus: Hedera token whale movements and unusual transfer patterns. While it lacks an explicit verb like 'monitors' or 'returns', the noun phrase plus the tool name makes the function clear. It differentiates from siblings like token_price or token_analyze by emphasizing whale/transfer monitoring.
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 gives no guidance on when to use this tool versus alternatives such as token_analyze or hcs_monitor. '0.2 HBAR' is a cost indicator, not an instruction about appropriate use. No conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_priceAHedera token price, market cap, 24h volume. 0.1 HBAR.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your HederaIntel API key | |
| token_id | Yes | Hedera token ID (e.g. 0.0.123456) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the cost ('0.1 HBAR') and specific data fields (price, market cap, volume), which is useful context beyond the annotations. No contradiction is present.
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 extremely concise, using two short sentences to convey purpose and cost without any wasted words or repetition of schema details.
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 read-only tool with well-covered schema and annotations, the description covers the core functionality and cost. However, it lacks usage guidance and sibling differentiation, and there is no output schema but return fields are hinted. Adequate but with clear 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% with clear descriptions for both parameters. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
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 provides price, market cap, and 24h volume for a Hedera token. Although it lacks a verb and does not explicitly differentiate from sibling tools like token_analyze and token_monitor, the purpose is unambiguous.
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. The mention of '0.1 HBAR' indicates a cost but does not explain the intended use case or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
