Skip to main content
Glama

get_sip010_info

Retrieve comprehensive SIP-010 token details including name, symbol, decimals, total supply, and metadata URI from Stacks blockchain contracts.

Instructions

Get complete information about a SIP-010 fungible token including name, symbol, decimals, total supply, and metadata URI.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contractAddressYesThe contract address
contractNameYesThe contract name of the SIP-010 token
networkYesThe Stacks network

Implementation Reference

  • The execute handler for the 'get_sip010_info' tool. Fetches SIP-010 token metadata (name, symbol, decimals, supply, URI) by calling multiple read-only contract functions via Hiro API and formats the response.
    export const getSIP010InfoTool: Tool<undefined, typeof SIP010TokenInfoScheme> = {
      name: "get_sip010_info",
      description: "Get complete information about a SIP-010 fungible token including name, symbol, decimals, total supply, and metadata URI.",
      parameters: SIP010TokenInfoScheme,
      execute: async (args, context) => {
        try {
          await recordTelemetry({ action: "get_sip010_info" }, context);
          
          // Get all token information in parallel
          const [nameResult, symbolResult, decimalsResult, supplyResult, uriResult] = await Promise.all([
            callReadOnlyFunction(args.contractAddress, args.contractName, "get-name", [], args.network),
            callReadOnlyFunction(args.contractAddress, args.contractName, "get-symbol", [], args.network),
            callReadOnlyFunction(args.contractAddress, args.contractName, "get-decimals", [], args.network),
            callReadOnlyFunction(args.contractAddress, args.contractName, "get-total-supply", [], args.network),
            callReadOnlyFunction(args.contractAddress, args.contractName, "get-token-uri", [], args.network),
          ]);
          
          // Parse results
          const name = nameResult.okay ? nameResult.result.replace(/"/g, '') : 'Unknown';
          const symbol = symbolResult.okay ? symbolResult.result.replace(/"/g, '') : 'Unknown';
          const decimals = decimalsResult.okay ? parseInt(decimalsResult.result.replace('u', '')) : 0;
          const totalSupply = supplyResult.okay ? parseInt(supplyResult.result.replace('u', '')) : 0;
          const uri = uriResult.okay && uriResult.result !== 'none' ? uriResult.result : 'No URI';
          
          return `# SIP-010 Token Information
    
    **Contract**: ${args.contractAddress}.${args.contractName}
    **Network**: ${args.network}
    
    ## Token Details
    - **Name**: ${name}
    - **Symbol**: ${symbol}
    - **Decimals**: ${decimals}
    - **Total Supply**: ${totalSupply} base units (${totalSupply / Math.pow(10, decimals)} ${symbol})
    - **Metadata URI**: ${uri}
    
    ## Contract Verification
    ✅ This contract implements the SIP-010 standard trait.
    
    ## Usage Notes
    - All amounts are in base units (multiply by 10^${decimals} for human amounts)
    - Post-conditions are REQUIRED for all transfers
    - Use native Stacks post-conditions for security`;
          
        } catch (error) {
          return `❌ Failed to get SIP-010 token info: ${error}`;
        }
      },
    };
  • Zod input schema for the get_sip010_info tool, defining required parameters: contractAddress, contractName, and network.
    const SIP010TokenInfoScheme = z.object({
      contractAddress: z.string().describe("The contract address"),
      contractName: z.string().describe("The contract name of the SIP-010 token"),
      network: NetworkScheme.describe("The Stacks network"),
    });
  • Registration of the getSIP010InfoTool (get_sip010_info) with the FastMCP server.
    server.addTool(getSIP010InfoTool);
  • Helper function used by get_sip010_info to call read-only Clarity functions on Stacks contracts using the Hiro API.
    async function callReadOnlyFunction(
      contractAddress: string,
      contractName: string,
      functionName: string,
      functionArgs: any[],
      network: string
    ): Promise<any> {
      const apiUrl = network === "mainnet" 
        ? "https://api.hiro.so" 
        : "https://api.testnet.hiro.so";
      
      try {
        const response = await fetch(
          `${apiUrl}/v2/contracts/call-read/${contractAddress}/${contractName}/${functionName}`,
          {
            method: "POST",
            headers: { "Content-Type": "application/json" },
            body: JSON.stringify({
              sender: contractAddress,
              arguments: functionArgs,
            }),
          }
        );
        
        if (!response.ok) {
          const data: any = await response.json();
          throw new Error(data.error || `HTTP ${response.status}`);
        }
        
        return await response.json();
      } catch (error) {
        throw new Error(`Failed to call ${functionName}: ${error}`);
      }
    }
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 describes the output content (token info attributes) but lacks behavioral details such as whether this is a read-only operation, potential rate limits, error conditions, or response format. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.

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 and lists key output attributes without unnecessary details. 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.

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 covers the purpose and output attributes adequately but lacks behavioral context (e.g., read-only nature, error handling) and doesn't explain return values beyond listing attributes. For a tool with 3 parameters and no structured output, 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all parameters well-documented in the schema (contractAddress, contractName, network with enum). The description adds no parameter-specific information beyond implying these are needed to fetch token info, 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 verb 'Get' and resource 'complete information about a SIP-010 fungible token' with specific attributes listed (name, symbol, decimals, total supply, metadata URI). It distinguishes from some siblings like 'get_sip010_balance' (balance vs. token info) but doesn't explicitly differentiate from 'get_sip009_token_info' or 'get_sip009_collection_info' which are similar for different token standards.

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 'get_sip010_balance' (for balance queries) or 'get_sip009_token_info' (for SIP-009 tokens). It states what it does but not when it's appropriate, leaving the agent to infer usage from context alone.

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/exponentlabshq/stacks-clarity-mcp'

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