Zetrix MCP Server

Official

by Zetrix-Chain

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
The tool set has clear thematic grouping (e.g., crypto, account, contract, SDK, WebSocket), but there is notable overlap within groups. For example, zetrix_get_account, zetrix_get_account_base, and zetrix_get_balance all retrieve account-related data with subtle distinctions that could confuse agents. Similarly, multiple contract call tools (zetrix_call_contract, zetrix_sdk_call_contract) and transaction submission tools (zetrix_submit_transaction, zetrix_ws_submit_transaction) have overlapping purposes, though descriptions provide some guidance.
Naming Consistency5/5
Tool names follow a highly consistent pattern throughout: all start with 'zetrix_' prefix, use snake_case uniformly, and employ a verb_noun structure (e.g., zetrix_get_balance, zetrix_create_keypair). Minor deviations like 'zetrix_multi_query' (adjective_verb_noun) are rare and do not disrupt readability, maintaining excellent predictability across all 44 tools.
Tool Count2/5
With 44 tools, the server is overly broad and heavy for a single MCP server, likely covering multiple domains (blockchain interaction, smart contract development, cryptography, WebSocket management). This high count increases complexity and cognitive load for agents, making it difficult to navigate efficiently. A more modular approach with separate servers for distinct functionalities would be more appropriate.
Completeness4/5
The tool surface is extensive and covers core blockchain operations comprehensively, including account management, transaction handling, contract development, and real-time updates. However, there are minor gaps: for instance, tools for updating or deleting accounts are missing, and some advanced contract management features (e.g., contract deployment or upgrade) are not explicitly covered, though the provided guides and generation tools mitigate this.
Average 3.1/5 across 44 of 44 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 'Get completed transaction records,' implying a read-only operation, but lacks details on permissions, rate limits, pagination, or what 'completed' entails (e.g., confirmed vs. pending). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more structured by explicitly mentioning optional parameters or output format to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a read operation with two parameters, the description is incomplete. It doesn't explain return values (e.g., list format, fields), error conditions, or how 'completed' is defined, leaving the agent under-informed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('hash' and 'ledgerSeq') documented as optional. The description doesn't add meaning beyond the schema (e.g., how parameters interact or default behavior), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get completed transaction records' clearly states the verb ('Get') and resource ('completed transaction records'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'zetrix_get_transaction' or 'zetrix_get_transaction_cache', which likely retrieve similar data, leaving ambiguity about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'zetrix_get_transaction' (likely for single transactions) and 'zetrix_get_transaction_cache' (possibly cached data), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Execute multiple API queries simultaneously', implying a write or action operation, but doesn't specify if it's read-only, destructive, requires authentication, has rate limits, or what the output looks like. For a tool with no annotations, this is a significant gap in transparency about its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'Execute multiple API queries simultaneously'. It's front-loaded and appropriately sized for the tool's apparent complexity, making it easy to parse without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing multiple queries, no annotations, and no output schema, the description is incomplete. It lacks details on query format, error handling, concurrency limits, or return values, which are crucial for an agent to use this tool effectively. The description doesn't compensate for the missing structured data, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'items' parameter documented as 'Array of query objects'. The description doesn't add any meaning beyond this, such as the structure of query objects or examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute multiple API queries simultaneously' states a clear verb ('Execute') and resource ('multiple API queries'), but it's vague about what type of queries these are (e.g., blockchain-related vs. general) and doesn't distinguish from siblings like 'zetrix_call_contract' or 'zetrix_sdk_call_contract' that might handle similar operations. It provides a basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description doesn't mention any prerequisites, context (e.g., for batch operations), or exclusions, leaving it unclear compared to single-query siblings like 'zetrix_get_account' or 'zetrix_get_transaction'. This lack of usage context makes it harder for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('Get'), but doesn't disclose behavioral traits like whether it requires authentication, rate limits, error conditions, or the format of returned documentation. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes essential details (the three standards) without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'specification' entails (e.g., technical details, usage examples) or the return format, leaving the agent uncertain about the tool's output and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'standard' fully documented in the schema (including enum values). The description adds no additional meaning beyond restating the enum values, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('token standard specification'), specifying the three possible standards (ZTP20, ZTP721, ZTP1155). It distinguishes this as a documentation retrieval tool, but doesn't explicitly differentiate from sibling tools like 'zetrix_contract_get_structure_guide' or 'zetrix_contract_get_testing_guide' which might also provide documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description doesn't mention prerequisites, context (e.g., during contract development), or compare it to other 'get' tools in the sibling list, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool decrypts a private key with a password, implying it's a read-only operation that returns the decrypted key, but it doesn't disclose critical behavioral traits such as security implications (e.g., handling sensitive data), error conditions (e.g., invalid password), or output format (e.g., raw key vs. structured data).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cryptographic operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., the decrypted private key format), security considerations, or error handling, leaving significant gaps for an AI agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('encryptedData' and 'password'). The description adds no additional meaning beyond what's in the schema, such as format details (e.g., keystore JSON structure) or usage notes. With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('decrypt') and the resource ('encrypted private key'), specifying it requires a password. It distinguishes from sibling 'zetrix_crypto_encrypt_key' by being the inverse operation. However, it doesn't explicitly differentiate from other crypto tools like 'zetrix_crypto_validate_key' or 'zetrix_crypto_sign' in terms of use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an encrypted key from 'zetrix_crypto_encrypt_key'), exclusions, or scenarios where other tools like 'zetrix_crypto_validate_key' might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool encrypts a private key with a password for secure storage, which implies a write/mutation operation but lacks details on encryption algorithm, security implications, error conditions, or output format. For a cryptographic tool with zero annotation coverage, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a cryptographic encryption tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as the encryption method, security warnings, expected output (e.g., encrypted key format), or error handling, which are essential for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 ('privateKey' and 'password'). The description adds no additional parameter semantics beyond what the schema provides, such as format requirements (e.g., key encoding, password strength) or examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('encrypt') and target ('private key') with the purpose ('for secure storage'). It distinguishes from siblings like 'zetrix_crypto_decrypt_key' by specifying encryption rather than decryption. However, it doesn't explicitly differentiate from other key-related tools like 'zetrix_crypto_generate_keypair' or 'zetrix_crypto_validate_key' beyond the encryption focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a private key from generation or import), when not to use it (e.g., if key is already encrypted), or direct comparisons to siblings like 'zetrix_crypto_decrypt_key' for reverse operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't specify whether this involves network calls, cryptographic computation, rate limits, error conditions, or what format the address will be in. For a cryptographic tool with zero annotation coverage, this minimal description leaves important behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for this simple tool and gets straight to the point with zero unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a cryptographic conversion tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the address will be in (hex, base58, etc.), whether this is a deterministic computation or involves lookups, or what happens with invalid public keys. For a tool that performs cryptographic operations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'publicKey' well-documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get Zetrix address from public key', which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'zetrix_crypto_get_public_key' (which goes in the opposite direction) and 'zetrix_get_account' (which might retrieve account info by address). However, it doesn't explicitly differentiate from all siblings, such as 'zetrix_create_keypair' which might also produce addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a public key first), when this conversion is necessary, or what to do if you already have an address. With many sibling tools available, this lack of contextual guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation without behavioral details. It doesn't disclose if this is a read-only operation, what cryptographic algorithm is used, error conditions (e.g., invalid key format), performance implications, or security considerations like handling sensitive private key input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words—it directly states the tool's purpose without unnecessary elaboration. Every word earns its place, making it highly efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (cryptographic operation with a private key input), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the output is (e.g., public key format), error handling, or security context, leaving significant gaps for an AI agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'privateKey' parameter is fully documented in the schema as 'The encrypted private key'), so the baseline is 3. The description adds no additional parameter meaning beyond what the schema provides, such as format specifics (e.g., hex encoding) or encryption details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Derive') and target resource ('public key from private key'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'zetrix_crypto_generate_keypair' or 'zetrix_crypto_get_address', but it's specific enough to avoid confusion about its core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a private key first), compare to 'zetrix_crypto_generate_keypair' (which might create both keys), or specify use cases like key derivation for transactions or verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing critical behaviors. It doesn't mention security implications (e.g., private key handling), output format (e.g., returns a signature as hex), error conditions, or side effects like whether the key is stored or modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cryptographic operations, no annotations, and no output schema, the description is incomplete. It lacks details on return values (e.g., signature format), error handling, security warnings, or how it integrates with sibling tools, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('message' and 'privateKey') well-documented in the schema. The description adds no additional meaning beyond the schema, such as format details (e.g., 'message' as hex string is already in schema) or constraints, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('sign a message') and the resource ('with a private key'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'zetrix_crypto_verify' (which likely verifies signatures) or 'zetrix_crypto_generate_keypair' (which creates keys), missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't mention when to choose this over 'zetrix_crypto_verify' for signature operations or relate to key generation tools. The description offers no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool validates formats, but doesn't describe what validation entails (e.g., checksum verification, length checks, error handling), whether it's read-only or has side effects, or what the output might look like (e.g., success/failure, error messages). This leaves significant gaps for a tool with potential security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Validate private key, public key, or address format.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple validation tool. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (cryptographic validation with no annotations and no output schema), the description is incomplete. It lacks details on validation behavior, output format (e.g., boolean result or error details), and how it differs from sibling tools. For a tool that could impact security decisions, more context is needed to be fully helpful to an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear descriptions for both parameters ('type' and 'value'). The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain format expectations for 'value' or validation rules). Given the high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate private key, public key, or address format.' It specifies the verb ('validate') and the resources (three types of cryptographic elements). However, it doesn't explicitly distinguish this validation tool from sibling tools like 'zetrix_crypto_get_address' or 'zetrix_crypto_get_public_key', which might retrieve rather than validate these elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a key/address to validate), exclusions, or comparisons to siblings like 'zetrix_create_keypair' or 'zetrix_crypto_generate_keypair', which might generate keys rather than validate them. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. While 'verify' implies a read-only, non-destructive operation, the description doesn't explicitly state this. It also omits important behavioral details like what cryptographic algorithm is used, whether the verification is deterministic, what happens on failure (e.g., returns false vs throws error), or any rate limits. For a cryptographic verification tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward verification tool and is front-loaded with the essential action. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cryptographic verification and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., boolean success/failure, detailed validation result), doesn't mention error conditions, and provides no context about the cryptographic ecosystem. For a tool that could have security implications, this leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions all three parameters (signature, message, public key) but adds no semantic information beyond what the schema already provides. With 100% schema description coverage where each parameter has clear descriptions, the description doesn't enhance understanding of parameter relationships, formats (beyond 'hex string' for message), or validation requirements. This meets the baseline for high schema coverage but doesn't add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('verify') and identifies the key resources involved (signature, message, public key). It distinguishes this as a verification operation rather than signing or key generation, which helps differentiate it from sibling tools like zetrix_crypto_sign and zetrix_crypto_generate_keypair. However, it doesn't explicitly contrast with those siblings in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a signature from zetrix_crypto_sign), when verification is appropriate (e.g., after receiving signed data), or what scenarios require this tool over other cryptographic operations. With many sibling tools in the crypto and contract domains, this lack of contextual guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions retrieving 'account information including balance and metadata', which implies a read-only operation, but does not disclose behavioral traits such as permissions required, rate limits, error handling, or what specific metadata is returned. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get Zetrix account information') and includes key details ('including balance and metadata'). There is no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage guidelines, and output format, which are needed for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'address' documented as 'The Zetrix account address'. The description does not add any meaning beyond this, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('Get') and resource ('Zetrix account information'), including what information is retrieved ('balance and metadata'). It distinguishes from some siblings like 'zetrix_get_balance' (which only gets balance) but not from 'zetrix_get_account_base' or 'zetrix_get_account_metadata' (which might overlap).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'zetrix_get_balance', 'zetrix_get_account_base', or 'zetrix_get_account_metadata'. It lacks explicit when/when-not instructions or named alternatives, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's non-destructive, but lacks details on permissions, rate limits, error conditions, or return format. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns structured metadata. It doesn't explain what 'metadata' entails (e.g., types of data, format) or behavioral aspects like error handling. For a read operation in a complex sibling environment, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 ('address' and 'key'). The description adds no additional meaning beyond the schema, such as format examples or usage context for the optional 'key'. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('metadata associated with an account'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'zetrix_get_account' or 'zetrix_get_account_base', which might also retrieve account information, leaving some ambiguity about what specifically distinguishes this metadata retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools related to accounts (e.g., 'zetrix_get_account', 'zetrix_get_account_assets'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'gets information' without detailing behavioral traits like read-only nature, potential errors, rate limits, or response format. It misses critical context for safe and effective use, such as whether it's a query or mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, efficiently conveying the core purpose. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex block data. It fails to explain what information is retrieved, error conditions, or behavioral aspects, leaving significant gaps for an AI agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the 'blockNumber' parameter. The description adds no additional meaning beyond implying the parameter is for querying by height, aligning with the baseline score when schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get information') and resource ('about a specific block by height'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'zetrix_get_latest_block' or specify what type of information is returned, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'zetrix_get_latest_block' for the latest block or 'zetrix_get_ledger' for broader data. The description lacks context about prerequisites or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if it's read-only, has rate limits, authentication needs, or what format the information is returned in, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get block/ledger information') and adds necessary qualification ('with optional details'). There is no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits, which is inadequate for a tool with multiple parameters and siblings in a complex domain like blockchain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds minimal value by implying parameters control optional details, but doesn't provide additional meaning beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('block/ledger information'), making the purpose understandable. It distinguishes from siblings like 'zetrix_get_block' by mentioning 'optional details' but doesn't explicitly differentiate beyond that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'zetrix_get_block' or 'zetrix_get_latest_block'. The description mentions 'optional details' but doesn't specify contexts or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get transaction details' which implies a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error handling, or what 'details' include (e.g., status, timestamp, fees). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, with every part contributing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'transaction details' include (e.g., JSON structure, fields), potential errors, or behavioral context. For a tool with rich sibling tools and no structured support, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'hash' parameter fully documented. The description adds no additional meaning beyond the schema, such as hash format or validation rules. According to rules, baseline is 3 when schema coverage is high (>80%) and no param info is in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('transaction details'), specifying the action and target. It distinguishes from some siblings like 'zetrix_get_transaction_history' by focusing on a single transaction via hash, but doesn't explicitly differentiate from all similar tools like 'zetrix_get_transaction_blob' or 'zetrix_get_transaction_cache'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites, context, or compare with sibling tools like 'zetrix_get_transaction_history' for historical data or 'zetrix_get_transaction_blob' for raw data, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool serializes data but doesn't reveal if this is read-only, whether it validates the transaction object, potential error conditions, or performance aspects like rate limits. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and output. There is no wasted verbiage or redundancy, making it easy for an agent to parse quickly. It earns its place by succinctly conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (serialization tool with nested object parameter) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the hexadecimal output represents, how errors are handled, or dependencies on other tools. For a tool in a rich sibling environment, more context is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'transaction' fully documented in the schema as an object with specific fields. The description adds no additional semantic details about the parameter beyond implying it's the input data. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Serialize') and the resource ('transaction data'), specifying the output format ('hexadecimal format'). It distinguishes from siblings like zetrix_submit_transaction or zetrix_get_transaction by focusing on serialization rather than submission or retrieval. However, it doesn't explicitly differentiate from all siblings, such as those involving contract calls or SDK operations, which slightly limits its specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a valid transaction object), exclusions, or comparisons to siblings like zetrix_submit_transaction (which might handle serialization internally). This leaves the agent without context for tool selection in a crowded sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves pending transactions, implying a read-only operation, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what 'not yet executed' entails (e.g., timeouts, cancellation). This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for a simple tool, making it easy for an AI agent to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of transactions, their statuses, or metadata), leaving the AI agent uncertain about the response format. For a tool with two parameters and no structured output, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters as optional. The description adds no additional meaning beyond the schema, such as default values for 'limit' or how 'hash' filters results. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('pending transactions not yet executed'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'zetrix_get_transaction' or 'zetrix_get_transaction_history', which likely retrieve different types of transaction data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like 'zetrix_get_transaction' and 'zetrix_get_transaction_history', the description lacks context on whether this is for real-time monitoring, debugging, or other specific scenarios, offering no explicit or implied usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool reads balance data, implying it's a read-only operation, but doesn't mention potential side effects, authentication requirements, rate limits, or error handling. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the balance output includes (e.g., currency, format), potential errors, or how it differs from sibling tools. For a read operation with no structured context, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'address' parameter fully documented. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get account balance') and the method ('using the official SDK'), which distinguishes it from the sibling tool 'zetrix_get_balance' that likely uses a different method. However, it doesn't specify the exact resource beyond 'account balance', leaving some ambiguity about what type of balance is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'zetrix_get_balance' or other account-related tools. It mentions the SDK method but doesn't explain why or when this is preferable, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 what the tool does ('Get account nonce') but lacks behavioral details: it doesn't specify if this is a read-only operation (implied but not explicit), potential errors (e.g., invalid address), rate limits, network calls, or return format. For a tool with zero annotation coverage, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a helpful parenthetical clarification. Every word earns its place, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter (100% schema coverage), the description is incomplete. It lacks behavioral context (e.g., safety, errors, return format) and usage guidance, which are critical for an AI agent to invoke this correctly in a blockchain context. The conciseness comes at the cost of necessary detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'address' parameter is fully described in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's in the schema—it doesn't explain address format, validation, or examples. It meets the minimum for adequate parameter documentation given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('account nonce'), with the parenthetical clarifying it's a 'transaction sequence number'. It distinguishes from siblings like 'zetrix_get_account' or 'zetrix_get_transaction' by focusing specifically on nonce retrieval. However, it doesn't explicitly differentiate from all possible alternatives in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description doesn't mention prerequisites (e.g., needing an address), use cases (e.g., before submitting a transaction), or comparisons to siblings like 'zetrix_get_account' which might also provide nonce information. It's a basic functional statement without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool checks activation status but does not disclose behavioral traits like whether it's a read-only operation, potential rate limits, error conditions, or what 'activated' means in this context. This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary details. It is front-loaded and appropriately sized for a simple check operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on what 'activated' entails, the return format, error handling, or how it differs from sibling tools. For a blockchain context with multiple account-related tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'address' documented as 'The Zetrix account address.' The description does not add meaning beyond this, such as address format or validation rules. With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if an account is activated on the blockchain.' It specifies the verb ('check') and resource ('account'), but does not differentiate from siblings like 'zetrix_get_account' or 'zetrix_get_account_base' which might provide overlapping information about account status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings such as 'zetrix_get_account' and 'zetrix_get_account_assets' that might include activation status, the description lacks explicit context or exclusions for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool submits for 'execution,' implying a write/mutation operation, but lacks details on permissions, rate limits, irreversible effects, or response behavior. This is inadequate for a tool that likely alters blockchain state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, this is a mutation tool with significant behavioral gaps. The description doesn't explain what happens on success/failure, return values, or error conditions. It's incomplete for a tool that submits transactions to a blockchain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter documentation, so the baseline is 3. The description adds no extra meaning about parameters beyond implying 'signed' relates to 'signatures,' which is already covered in the schema. No compensation is needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('submit') and target ('signed transaction to blockchain for execution'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'zetrix_ws_submit_transaction' or 'zetrix_test_transaction', which appear to serve similar submission functions, preventing a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'zetrix_ws_submit_transaction' (WebSocket-based) and 'zetrix_test_transaction' (likely for testing), there's clear potential for confusion, but the description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions 'real-time updates' but doesn't specify what happens after connection (e.g., does it start receiving updates automatically, require separate subscriptions, or maintain persistent connection?). No information on authentication needs, rate limits, error handling, or what 'register' entails operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by separating connection and registration aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a WebSocket connection tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'real-time updates' include, how to use them after connection, potential side effects (e.g., background processes), or return values. Given the complexity of real-time systems and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'apiList', which is documented as 'Optional list of API message types to register (numbers)'. The description adds no additional parameter context beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Connect and register') and resource ('Zetrix WebSocket'), specifying it's for 'real-time updates'. It distinguishes from siblings like zetrix_ws_disconnect and zetrix_ws_status by focusing on connection initiation, but doesn't explicitly differentiate from other WebSocket tools like zetrix_ws_subscribe_tx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., needing an active connection before using other WebSocket tools), when not to use it (e.g., if already connected), or compare to siblings like zetrix_ws_subscribe_tx for specific subscription needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions subscribing to notifications but doesn't disclose behavioral traits such as whether this is a persistent subscription, how notifications are delivered, rate limits, authentication needs, or error handling. This leaves significant gaps for a tool that likely involves real-time updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a WebSocket subscription tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after subscription (e.g., notification format, how to receive updates), potential side effects, or integration with other WebSocket tools, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'addresses' parameter clearly documented. The description adds minimal value beyond this, as it only restates that addresses are involved without providing additional context like format examples or constraints. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('subscribe') and resource ('transaction notifications for specific addresses'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'zetrix_ws_connect' or 'zetrix_ws_submit_transaction', which are also WebSocket-related, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 is provided. It doesn't mention prerequisites (e.g., needing a WebSocket connection via 'zetrix_ws_connect'), exclusions, or comparisons to other subscription or transaction tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'checks' health status, implying a read-only operation, but doesn't disclose behavioral traits such as what 'health' entails (e.g., uptime, connectivity, performance), potential rate limits, authentication needs, or response format, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it efficient and easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimal. It lacks details on what 'health status' includes, how results are returned, or any operational context, making it incomplete for effective use by an AI agent, especially with no annotations to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add parameter semantics, but with no parameters, this is acceptable, and it doesn't contradict the schema, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and resource ('health status of the Zetrix node'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'zetrix_ws_status' or 'zetrix_get_latest_block', which might also relate to node status, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'zetrix_ws_status' that might check WebSocket status, the description lacks context on whether this is for overall node health, specific components, or diagnostic purposes, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get asset holdings', implying a read-only operation, but does not specify details like whether it returns all assets or filtered ones, pagination, error handling, or authentication needs. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly conveys the core purpose without unnecessary elaboration, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, and output format. With no output schema, it should ideally hint at return values, but it does not, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting all parameters clearly. The description does not add any additional meaning beyond the schema, such as explaining the relationship between 'code' and 'issuer' or providing examples. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'asset holdings for an account', making the purpose specific and understandable. However, it does not distinguish this tool from potential sibling tools like 'zetrix_get_balance' or 'zetrix_get_account', which might overlap in functionality, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as 'zetrix_get_balance' or 'zetrix_get_account', which could also retrieve account-related data. There is no mention of prerequisites, exclusions, or specific contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 it 'gets' information, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication requirements, network dependencies, or what specific information is returned (e.g., block number, timestamp, transactions). For a blockchain query tool, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without any fluff. It's front-loaded with the main action and resource, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'block information' includes (e.g., fields returned), potential errors, or dependencies. For a blockchain tool where output details matter, this leaves the agent with insufficient context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, so it appropriately avoids redundant information. A baseline of 4 is applied since no parameters exist, and the description doesn't add unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('latest block information from Zetrix blockchain'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'zetrix_get_block' (which likely retrieves a specific block), leaving some ambiguity about when to choose this tool over that one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like 'zetrix_get_block' (for specific blocks) and 'zetrix_get_ledger' (possibly for broader ledger data), there's no indication of when this tool is preferred or what distinguishes it from similar queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a write operation ('Create') but doesn't disclose behavioral traits like whether this requires authentication, what happens on failure (e.g., error handling), or if it has side effects like generating keys. The description is minimal and misses critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the key action ('Create a new Zetrix account') and adds necessary context ('using the official SDK'), 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of account creation (a write operation with potential side effects), no annotations, and no output schema, the description is inadequate. It lacks details on success/failure outcomes, error handling, or any behavioral context, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is acceptable here, but it could have mentioned if any implicit parameters (like SDK context) are required, though not strictly necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new Zetrix account'), and specifies the method ('using the official SDK'). It distinguishes from sibling tools like 'zetrix_create_keypair' by focusing on account creation rather than key generation, though it doesn't explicitly contrast with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'zetrix_create_keypair' or 'zetrix_get_account'. The description lacks context about prerequisites, such as needing SDK setup or network connectivity, and doesn't mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Disconnect from WebSocket' implies a state-changing operation, but it doesn't describe whether this is destructive (e.g., terminates active connections), has side effects (e.g., affects other tools), requires specific permissions, or provides any feedback. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Disconnect from WebSocket'. It is front-loaded with the core action, has zero waste, and is appropriately sized for a tool with no parameters. Every word earns its place by directly conveying the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is incomplete for contextual understanding. It doesn't explain what 'WebSocket' means in this server's context, what state changes occur, or what the agent should expect after invocation. For a tool that likely interacts with network connections, more context is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond the schema, which already fully covers the empty input. A baseline of 4 is appropriate as the description doesn't contradict or add unnecessary details about non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disconnect from WebSocket' clearly states the action (disconnect) and target resource (WebSocket), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'zetrix_ws_connect' by specifying the opposite operation. However, it doesn't explicitly mention what 'WebSocket' refers to in the context of the Zetrix server, leaving some ambiguity about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't specify prerequisites (e.g., must be connected first), conditions for disconnection, or what happens after disconnection. Given siblings like 'zetrix_ws_connect' and 'zetrix_ws_status', explicit usage context would help an agent decide when disconnection is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the sandbox environment and debugging purpose, which is helpful, but doesn't describe what 'call' entails (e.g., read-only vs. state-changing, error handling, or output format). For a contract interaction tool with 8 parameters, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information: action ('call smart contract'), environment ('sandbox'), and purpose ('debugging'). There's no wasted verbiage, making it appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of smart contract calls, 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or the implications of the sandbox environment (e.g., state persistence). For a debugging tool with many optional inputs, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all 8 parameters documented as optional. The description adds no additional parameter information beyond what's in the schema (e.g., it doesn't explain relationships between parameters like 'contractAddress' and 'code'). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('call smart contract') and context ('in sandbox environment for debugging'), which is specific and distinguishes it from production contract calls. However, it doesn't explicitly differentiate from sibling tools like 'zetrix_sdk_call_contract' or 'zetrix_sdk_invoke_contract', which appear to have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for debugging in a sandbox environment, which provides some context about when to use it (for testing rather than production). However, it doesn't specify when to choose this tool over alternatives like 'zetrix_sdk_call_contract' or 'zetrix_test_transaction', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Get guide' which suggests a read-only operation, but doesn't disclose behavioral traits such as whether it returns static documentation, requires authentication, has rate limits, or what format the guide is in. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('Get guide on testing Zetrix smart contracts') and adds specific detail ('with TEST_INVOKE and TEST_QUERY'). There is no wasted verbiage, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or integration context. For a guide-fetching tool, more information on the guide's content or usage would improve completeness, but it meets the basic threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed in the description. The description doesn't add any parameter details, which is acceptable given the baseline of 4 for zero parameters, as it doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'guide on testing Zetrix smart contracts', specifying it covers TEST_INVOKE and TEST_QUERY methods. It distinguishes from siblings like 'zetrix_contract_get_structure_guide' by focusing on testing rather than structure, but could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 is provided. The description implies usage for testing smart contracts, but it doesn't specify prerequisites, timing, or how it differs from other contract-related tools like 'zetrix_contract_get_chain_functions' or 'zetrix_test_transaction'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is to 'Get documentation', which implies a read-only operation, but doesn't specify details like whether it requires authentication, rate limits, error handling, or the format of the returned documentation. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without any wasted words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate for a simple read operation. However, it lacks details on the output format (e.g., structure of the documentation) and behavioral context, which could be important for an agent to use it effectively. It's complete enough for basic understanding but has room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, and since there are none, it doesn't need to compensate for any gaps. A baseline of 4 is given as it meets the requirement without unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get documentation' and the resource 'all built-in Utils object functions available in Zetrix smart contracts', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'zetrix_contract_get_chain_functions' or 'zetrix_contract_get_structure_guide', which appear to serve similar documentation purposes for different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other 'get' tools in the sibling list (e.g., 'zetrix_contract_get_chain_functions'). It lacks context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool creates a project structure, implying a write operation, but doesn't disclose behavioral traits such as permissions needed, whether it overwrites existing directories, error handling, or rate limits. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded with the main action and details. It efficiently conveys the purpose and key features (project structure, testing framework, examples, utilities) without unnecessary elaboration, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a tool with 2 parameters and 100% schema coverage. It covers the purpose and what is created, but lacks details on behavioral aspects like side effects, error cases, or return values, which are important for a tool that initializes an environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters ('contractName' and 'workingDirectory') with clear descriptions. The description adds no additional parameter semantics beyond implying the tool creates a project based on 'contractName', which aligns with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Initialize') and resource ('Zetrix smart contract development environment'), specifying it uses 'create-zetrix-tool' and creates a project structure with testing framework, examples, and utilities. It distinguishes from siblings like 'zetrix_contract_generate_advanced' by focusing on environment setup rather than contract generation, though it doesn't 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for starting a new development environment, but provides no explicit guidance on when to use this tool versus alternatives like 'zetrix_contract_generate_advanced' or prerequisites. It mentions the tool used ('create-zetrix-tool'), which gives some context, but lacks clear when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the outputs but doesn't cover critical aspects like whether this operation is safe (e.g., read-only or involves sensitive data generation), if it requires authentication, rate limits, or how the keys are generated (e.g., randomness, algorithm). This leaves significant gaps for a tool that likely handles cryptographic keys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that directly states what the tool does and its outputs, with no wasted words. It's front-loaded and easy to parse, making it highly efficient for an agent to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description adequately covers the basic purpose. However, for a crypto key generation tool with no annotations, it lacks details on security implications, output format, or error handling, which could be important for safe and effective use. The absence of an output schema means the description doesn't compensate by explaining return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, which is acceptable here as there are none to explain. It efficiently focuses on the tool's purpose without unnecessary repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate a new Zetrix key pair') and the outputs ('private key, public key, and address'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from the sibling tool 'zetrix_create_keypair', which appears to serve a similar function, leaving some ambiguity about when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as the sibling 'zetrix_create_keypair' or other crypto-related tools. It lacks context about prerequisites, typical use cases, or any exclusions, leaving the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'state change' (indicating mutation) and 'requires private key' (implying authentication), but fails to detail critical aspects like transaction costs, irreversible effects, rate limits, error handling, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information ('invoke a smart contract function with state change') and adds necessary constraint ('requires private key'). There is no wasted verbiage, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (state-changing contract invocation), lack of annotations, and absence of an output schema, the description is incomplete. It omits details on transaction outcomes, error scenarios, security implications, and how results are returned. For a high-stakes mutation tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear documentation for all 6 parameters. The description adds minimal value beyond the schema, only implying that 'privateKey' is required for signing. No additional syntax, format details, or contextual meaning are provided, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('invoke a smart contract function with state change') and resource ('smart contract'), making the purpose evident. It distinguishes from sibling 'zetrix_call_contract' by specifying 'state change', but could be more explicit about the difference. The description is not tautological and provides meaningful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'requires private key', which suggests authentication needs. However, it lacks explicit guidance on when to use this tool versus alternatives like 'zetrix_sdk_call_contract' or 'zetrix_call_contract', nor does it specify prerequisites or exclusions beyond the private key requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Check' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns real-time or cached data, or what happens if no WebSocket connection exists. For a tool with zero annotation coverage, this leaves significant behavioral gaps, though it correctly indicates a non-destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence ('Check WebSocket connection status') with zero wasted words. It efficiently conveys the core purpose without redundancy or fluff, making it easy for an AI agent to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on usage, behavioral traits, or output format. For a status-checking tool, more details on what 'status' includes (e.g., connected/disconnected, latency metrics) would enhance completeness, but it meets basic requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate. A baseline of 4 is applied for zero-parameter tools, as the description focuses on purpose without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check WebSocket connection status' clearly states the verb ('Check') and resource ('WebSocket connection status'), making the purpose immediately understandable. It distinguishes from siblings like 'zetrix_ws_connect' or 'zetrix_ws_disconnect' by focusing on status checking rather than connection management. However, it lacks specificity about what aspects of status are checked (e.g., connectivity, latency, session details), preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., requires an established WebSocket connection), exclusions, or comparisons to siblings like 'zetrix_check_health' (which might check broader system health). Usage is implied only by the name and purpose, with no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'real-time status updates' which hints at streaming behavior, but fails to disclose critical details: whether this is a blocking call, error handling, authentication requirements, rate limits, or what happens if the WebSocket is disconnected. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and benefit. Every word earns its place with no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a WebSocket-based transaction submission with no annotations and no output schema, the description is insufficient. It omits behavioral traits (e.g., streaming nature, error cases), does not explain the return values or status update format, and provides no context on integration with other WebSocket tools like 'zetrix_ws_connect'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters (transaction, signatures, trigger). The description adds no additional meaning about parameter usage, formats, or examples beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit transaction via WebSocket') and the key benefit ('get real-time status updates'), which distinguishes it from the sibling 'zetrix_submit_transaction' that likely uses a different method. However, it doesn't specify what type of transaction (e.g., contract invocation, transfer) or the exact resource involved beyond the generic 'transaction'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when real-time updates are needed via WebSocket, suggesting an alternative to non-WebSocket submission methods. However, it lacks explicit guidance on when to use this vs. 'zetrix_submit_transaction' or prerequisites like needing an active WebSocket connection from 'zetrix_ws_connect'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool is a read operation ('Get') and specifies content exclusions, but lacks critical behavioral details: whether it requires authentication, rate limits, error conditions, or response format. For a read tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and key limitation. Every word earns its place with zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 1 parameter (fully documented in schema) but no annotations or output schema, the description is minimally adequate. It clarifies scope vs. siblings, but lacks behavioral context (auth, errors, response format) that would be needed for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'address' parameter is fully documented in the schema), so the baseline is 3. The description adds no parameter-specific information beyond what the schema already provides, but doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('basic account information') with a specific scope limitation ('without assets and metadata'). It distinguishes from sibling tools like 'zetrix_get_account' (likely full account info) and 'zetrix_get_account_assets'/'zetrix_get_account_metadata' (specific components), but doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying what's excluded ('without assets and metadata'), suggesting this tool is for lightweight account overviews. However, it doesn't provide explicit when-to-use guidance, prerequisites, or direct comparisons with alternatives like 'zetrix_get_account' or 'zetrix_get_balance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format (balance in ZETA and ZETRIX units) and the conversion rate, but fails to address critical aspects like error handling (e.g., invalid addresses), rate limits, authentication needs, or whether this is a read-only operation. This leaves significant gaps for an agent to understand how to invoke it safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by essential return details and a unit conversion note. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description covers the basic purpose and return format adequately. However, it lacks details on behavioral aspects like error conditions or operational constraints, which are important for a tool interacting with a blockchain system. This results in a minimally viable but incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'address' parameter clearly documented. The description does not add any additional meaning beyond what the schema provides, such as address format examples or validation rules. According to the rules, with high schema coverage, the baseline score is 3, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the ZETRIX balance') and resource ('of an account'), distinguishing it from sibling tools like zetrix_get_account or zetrix_get_account_assets by focusing exclusively on balance retrieval. It also specifies the return format, which further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like zetrix_sdk_get_balance or other account-related tools. The description lacks context about prerequisites, such as whether the account must be activated or have a specific format, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool evaluates fees without submission, implying it's a read-only simulation, but does not disclose other traits such as rate limits, authentication needs, error handling, or what the evaluation entails (e.g., returns estimated costs). This leaves gaps in understanding the tool's behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Evaluate transaction fees without blockchain submission.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is minimally complete. It covers the purpose and implies usage but lacks details on behavioral traits and output format. Without annotations or an output schema, more context on what the evaluation returns would be beneficial, but the description is adequate for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'items' parameter documented as 'Array of test transaction items.' The description does not add further meaning beyond this, such as explaining what constitutes a 'test transaction item' or providing examples. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Evaluate transaction fees without blockchain submission.' It specifies the verb ('evaluate') and resource ('transaction fees') and distinguishes it from sibling tools like zetrix_submit_transaction by emphasizing 'without blockchain submission.' However, it doesn't explicitly differentiate from all siblings, such as zetrix_get_transaction, which might also involve transaction analysis but not fee evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'without blockchain submission,' suggesting this tool is for testing or simulation rather than actual execution. However, it lacks explicit guidance on when to use this tool versus alternatives like zetrix_submit_transaction or other transaction-related siblings, and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets' a guide, implying a read-only operation, but doesn't disclose behavioral traits such as whether it requires authentication, returns static or dynamic content, has rate limits, or error conditions. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('Get guide') and specifies the scope ('how to structure Zetrix smart contracts with ES5 patterns, classes, and inheritance'). There is no wasted verbiage, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description adequately covers the purpose and scope. However, it lacks details on behavioral aspects like return format or error handling, which would be beneficial for a tool with no structured data to rely on, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline of 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'guide on how to structure Zetrix smart contracts', specifying it covers ES5 patterns, classes, and inheritance. It distinguishes from siblings like zetrix_contract_get_testing_guide by focusing on structure rather than testing or other aspects, though it doesn't 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for structuring smart contracts with ES5 patterns, which suggests it's for developers needing guidance on contract design. However, it lacks explicit when-to-use guidance, prerequisites, or comparisons with siblings like zetrix_contract_generate_advanced, leaving usage context somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool generates a key pair and specifies it's 'for testing only', which hints at potential limitations (e.g., not for secure production use). However, it lacks details on what the output includes (e.g., format of keys, whether they're stored or transient), any rate limits, or security considerations, leaving significant gaps in transparency for a cryptographic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Generate a new public-private key pair') and adds a crucial qualifier ('for testing only') without any wasted words. Every part of the sentence earns its place by clarifying purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description provides a basic understanding of purpose and limited usage context. However, for a cryptographic key generation tool, it lacks details on output format (e.g., whether it returns JSON with public/private keys), security implications, or how it differs from siblings, making it minimally viable but incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately focuses on the tool's purpose. A baseline of 4 is applied as it compensates adequately for the lack of parameters by clearly stating what the tool does without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and resource ('new public-private key pair'), making the purpose evident. However, it doesn't distinguish this tool from its sibling 'zetrix_crypto_generate_keypair', which appears to serve a similar function, leaving room for confusion about why two separate tools exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'for testing only', which implies a specific context of use (testing environments) and suggests it might not be suitable for production. However, it doesn't explicitly state when to use this tool versus alternatives like 'zetrix_crypto_generate_keypair' or provide clear exclusions, leaving usage guidance 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the critical behavioral trait of being read-only ('query only, no state change'), which is essential for a contract interaction tool. However, it lacks details on permissions, rate limits, error handling, or response format, leaving gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and key constraint ('query only, no state change'). Every word earns its place with zero waste, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that interacts with smart contracts. It covers the read-only nature but misses details on authentication, response format, error cases, or how it differs from 'zetrix_call_contract'. For a 3-parameter tool with no structured support, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Call a smart contract function') and specifies it's for query-only purposes with no state change. It distinguishes from the sibling 'zetrix_sdk_invoke_contract' by emphasizing read-only behavior, though it doesn't explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'query only, no state change,' which suggests when to use this versus mutation tools. However, it doesn't explicitly name alternatives like 'zetrix_sdk_invoke_contract' or provide clear exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves documentation, implying a read-only operation, but does not disclose behavioral traits such as whether it requires authentication, rate limits, or the format of the returned documentation. This leaves gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimal but adequate for a simple documentation retrieval tool. However, without annotations or output details, it lacks completeness regarding behavioral context and return format, which could be important for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description appropriately does not discuss parameters, earning a baseline score of 4 for not adding unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get documentation' and specifies the resource 'all built-in Chain object functions available in Zetrix smart contracts.' It distinguishes from sibling tools like zetrix_contract_get_utils_functions by focusing specifically on Chain object functions rather than utilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when documentation for Chain object functions is needed, but it does not explicitly state when to use this tool versus alternatives like zetrix_contract_get_structure_guide or zetrix_contract_get_testing_guide. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the mandatory initialization dependency (critical behavioral constraint), error condition if workflow not followed, and mentions support for complex architectures. However, it doesn't specify performance characteristics, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose. The mandatory workflow instructions are clearly highlighted. While slightly dense, every sentence serves a purpose - no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 6-parameter tool with no annotations and no output schema, the description provides good context about the mandatory workflow and architectural support. However, it doesn't describe what the tool returns (output format) or error handling beyond the initialization requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 thoroughly. The description adds minimal parameter-specific context - it mentions using the same contractName from initialization and suggests outputDirectory format, but doesn't provide additional semantic meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates advanced multi-class Zetrix smart contracts with specific components (interfaces, libraries, utilities, main contract, test specs). It distinguishes from sibling tools by focusing on contract generation rather than querying, testing, or transaction submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow instructions: (1) first call zetrix_contract_init_dev_environment with contractName, (2) then call this tool with the same contractName and specific outputDirectory. It explicitly warns that calling without initialization will cause an error, and mentions support for complex architectures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![zetrix-mcp-server MCP server](https://glama.ai/mcp/servers/Zetrix-Chain/zetrix-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Zetrix-Chain/zetrix-mcp-server)

Score Badge

Copy to your README.md:

[![zetrix-mcp-server MCP server](https://glama.ai/mcp/servers/Zetrix-Chain/zetrix-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Zetrix-Chain/zetrix-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Zetrix-Chain/zetrix-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server