Skip to main content
Glama
Zzero-net

Zero Network MCP Server

by Zzero-net

zero_transaction_format

Retrieve standardized transaction formats and cryptographic primitives for implementing Zero Network payment systems, enabling developers to structure crypto-based transactions correctly.

Instructions

Get the Zero transaction wire format (136 bytes), account state format (48 bytes), and cryptographic primitives.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The handler function for the `zero_transaction_format` tool, which returns the `TRANSACTION_FORMAT` string.
    @mcp.tool()
    def zero_transaction_format() -> str:
        """Get the Zero transaction wire format (136 bytes), account state format (48 bytes), and cryptographic primitives."""
        return TRANSACTION_FORMAT
  • The definition of the Zero transaction format, account state, and cryptographic primitives, which is returned by the tool.
    TRANSACTION_FORMAT = """# Zero Transaction Format (136 bytes)
    
    ```
    ZeroTransfer {
        from:      [32 bytes]  // Ed25519 public key (sender)
        to:        [32 bytes]  // Ed25519 public key (recipient)
        amount:    [4 bytes]   // u32, in units (1 unit = 0.01 Z = $0.0001)
        nonce:     [4 bytes]   // u32, per-account monotonic counter
        signature: [64 bytes]  // Ed25519 full signature
    }
    // Total: 136 bytes
    ```
    
    ## Amount Encoding
    - Amount is in units, not Z. 1 Z = 100 units.
    - To send 0.50 Z, set amount = 50
    - To send 1.00 Z, set amount = 100
    - Max amount: 2500 units (25 Z = $0.25)
    
    ## Account State (48 bytes per account)
    ```
    Account {
        balance:  [4 bytes]   // u32, current balance in units
        nonce:    [4 bytes]   // u32, last transaction nonce
        head:     [32 bytes]  // BLAKE3 hash of latest block
        flags:    [8 bytes]   // reserved (frozen, validator, etc.)
    }
    ```
    
    ## Cryptographic Primitives
    - Signatures: Ed25519 (ed25519-dalek with verify_strict)
    - Hashing: BLAKE3 (256-bit, hardware-accelerated)
    - Wire signature: Full 64-byte Ed25519 signature
    """
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 it 'Get[s]' information, implying a read-only operation, but doesn't clarify if this requires authentication, has rate limits, or what the output entails (though an output schema exists). For a tool with zero annotation coverage, this is minimal 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 front-loads the purpose without any wasted words. It directly states what the tool provides, 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.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (simple retrieval with no parameters) and the presence of an output schema (which handles return values), the description is complete enough for its purpose. It specifies what formats and primitives are retrieved, though it could benefit from more behavioral context given the lack of annotations.

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 the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it doesn't. Baseline is 4 for zero parameters, as it appropriately avoids redundant 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 what the tool does: 'Get the Zero transaction wire format (136 bytes), account state format (48 bytes), and cryptographic primitives.' It specifies the verb 'Get' and the resources (formats and primitives). However, it doesn't explicitly distinguish this from sibling tools like zero_api_reference or zero_implementation_guide, which might also provide format information, so it misses full sibling 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. With siblings like zero_api_reference and zero_implementation_guide that might overlap, there's no indication of context, prerequisites, or exclusions. It's a basic statement of function without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/Zzero-net/mcp-server'

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