Skip to main content
Glama
kilkelly

Nano Currency MCP Server

by kilkelly

nano_my_account_info

Retrieve detailed Nano account information including balance, representative, and frontier block for the address used to send Nano.

Instructions

Retrieve detailed information about my Nano account/address, including balance (in Nano and raw units), representative, and frontier block. This is the account that is used to send Nano from.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function for the 'nano_my_account_info' tool. It validates the NANO_PRIVATE_KEY, derives the account address using getAddress(), fetches account info via getAccountInfo(), formats the balance with friendlyAmount(), and returns a formatted text response.
    async function () {  
      try {
        NANO_PRIVATE_KEY_SCHEMA.parse(process.env.NANO_PRIVATE_KEY)
    
        const myAddress = getAddress()
        let myAccountInfo =  await getAccountInfo(myAddress)
    
        return createTextResponse(`The account information for ${myAddress} is ` + JSON.stringify({ ...myAccountInfo, balance: friendlyAmount(myAccountInfo.balance) }))
      }
      catch (error) {
        console.error('[nano_my_account_info] Error:', error.message || error);
        return createErrorResponse(error)
      }    
    }
  • Registration of the 'nano_my_account_info' tool using server.tool(), including the tool name, description, empty parameters schema ({}), and the handler function.
    server.tool(
      'nano_my_account_info',
      'Retrieve detailed information about my Nano account/address, including balance (in Nano and raw units), representative, and frontier block. This is the account that is used to send Nano from.',
      {},
      async function () {  
        try {
          NANO_PRIVATE_KEY_SCHEMA.parse(process.env.NANO_PRIVATE_KEY)
    
          const myAddress = getAddress()
          let myAccountInfo =  await getAccountInfo(myAddress)
    
          return createTextResponse(`The account information for ${myAddress} is ` + JSON.stringify({ ...myAccountInfo, balance: friendlyAmount(myAccountInfo.balance) }))
        }
        catch (error) {
          console.error('[nano_my_account_info] Error:', error.message || error);
          return createErrorResponse(error)
        }    
      }
    )
  • Zod schema used within the handler to validate the NANO_PRIVATE_KEY environment variable.
    const NANO_PRIVATE_KEY_SCHEMA = z.string({
      required_error: `NANO_PRIVATE_KEY is required`,
    })
    .refine(val => N.checkKey(val), { message: `NANO_PRIVATE_KEY is not valid` })
  • Helper function called by the handler to fetch detailed account information from the Nano RPC endpoint.
    async function getAccountInfo(address) {
      return (
        await rpcCall(
          NANO_RPC_URL_KEY,
          'account_info',
          {
            account: address,
            representative: 'true'
          }
        )
      )
    }
  • Helper function used by the handler to derive the Nano address from the private key.
    function getAddress () {
      return N.deriveAddress(N.derivePublicKey(process.env.NANO_PRIVATE_KEY), { useNanoPrefix: true })
    }
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It clearly indicates this is a read-only operation ('retrieve'), but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or response format. The description adds some context about the account being used for sending Nano, but lacks comprehensive 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 perfectly concise with two sentences that each earn their place. The first sentence states the purpose and specific data returned, while the second provides important contextual clarification about which account is being referenced.

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 zero-parameter read tool with no annotations and no output schema, the description is adequate but has gaps. It explains what information will be retrieved but doesn't describe the response format, error conditions, or authentication requirements. Given the simplicity of the tool (0 params), it's minimally viable but could be more 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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what information will be retrieved about the account.

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 verb 'retrieve' and resource 'detailed information about my Nano account/address', listing specific data fields (balance, representative, frontier block). It distinguishes from sibling tools by specifying 'my account' (vs. nano_account_info for general accounts) and clarifying this is the sending account.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: to get information about the user's own Nano account. It distinguishes from nano_account_info (general accounts) and nano_send (sending transactions), though doesn't explicitly state when NOT to use it or mention block_info as an alternative for block-level data.

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

Related 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/kilkelly/nano-currency-mcp-server'

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