Skip to main content
Glama

validate_stacks_address

Verify Stacks blockchain address format and network compatibility to ensure valid transactions and interactions with the blockchain.

Instructions

Validate a Stacks address format and check if it's correctly formatted for the specified network.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesAddress to validate
networkNoNetwork to validate against

Implementation Reference

  • Full implementation of the validate_stacks_address tool, including the execute handler that performs address format validation, network prefix checking, and optional account info lookup.
    export const validateStacksAddressTool: Tool<undefined, typeof AddressValidationScheme> = {
      name: "validate_stacks_address",
      description: "Validate a Stacks address format and check if it's correctly formatted for the specified network.",
      parameters: AddressValidationScheme,
      execute: async (args, context) => {
        try {
          await recordTelemetry({ action: "validate_stacks_address" }, context);
          
          const address = args.address.trim();
          const network = args.network || 'mainnet';
          
          // Basic format validation
          const isValidFormat = /^S[TPMNX][A-Z0-9]{36,41}$/.test(address);
          
          if (!isValidFormat) {
            return `# Address Validation Result
    
    **Address**: ${address}
    **Valid Format**: ❌ No
    **Network**: ${network}
    
    ## Issues Detected
    - Address does not match Stacks address format
    - Expected format: S[TPMNX][A-Z0-9]{36-41}
    
    ## Valid Examples
    - **Mainnet**: SP1H1733V5MZ3SZ9XRW9FKYGEZT0JDGEB8Y634C7R
    - **Testnet**: ST1PQHQKV0RJXZFY1DGX8MNSNYVE3VGZJSRTPGZGM
    
    ## Next Steps
    - Check address spelling and format
    - Ensure you're using the correct network prefix (SP for mainnet, ST for testnet)`;
          }
    
          // Network-specific validation
          const prefix = address.substring(0, 2);
          const expectedMainnetPrefix = 'SP';
          const expectedTestnetPrefix = 'ST';
          
          let networkMatch = true;
          let actualNetwork = 'unknown';
          
          if (prefix === expectedMainnetPrefix) {
            actualNetwork = 'mainnet';
            networkMatch = (network === 'mainnet');
          } else if (prefix === expectedTestnetPrefix) {
            actualNetwork = 'testnet';
            networkMatch = (network === 'testnet');
          } else {
            networkMatch = false;
          }
    
          // Try to get additional info if address is valid
          let additionalInfo = '';
          if (isValidFormat && networkMatch) {
            try {
              const apiService = new StacksApiService();
              const validNetwork = network as "mainnet" | "testnet" | "devnet";
              const accountInfo = await apiService.getAccountInfo(address, validNetwork);
              const balance = (parseInt(accountInfo.balance) / 1000000).toLocaleString();
              
              additionalInfo = `\n## Account Status
    - **STX Balance**: ${balance} STX
    - **Account Nonce**: ${accountInfo.nonce}
    - **Status**: Account exists and is active`;
              
            } catch (error) {
              additionalInfo = `\n## Account Status
    - **Status**: Valid format but account may not exist or be inactive
    - **Note**: ${error}`;
            }
          }
    
          return `# Address Validation Result
    
    **Address**: ${address}
    **Valid Format**: ${isValidFormat ? '✅ Yes' : '❌ No'}
    **Expected Network**: ${network}
    **Actual Network**: ${actualNetwork}
    **Network Match**: ${networkMatch ? '✅ Yes' : '❌ No'}
    
    ## Address Details
    - **Prefix**: ${prefix}
    - **Length**: ${address.length} characters
    - **Format**: ${isValidFormat ? 'Correct Stacks address format' : 'Invalid format'}
    
    ${!networkMatch && isValidFormat ? `\n⚠️ **Network Mismatch**: Address is for ${actualNetwork} but you specified ${network}` : ''}
    
    ${additionalInfo}
    
    ## Supported Networks
    - **Mainnet**: Addresses start with 'SP'
    - **Testnet**: Addresses start with 'ST'`;
          
        } catch (error) {
          return `❌ Failed to validate address: ${error}`;
        }
      },
    };
  • Zod schema defining the input parameters for the validate_stacks_address tool.
    const AddressValidationScheme = z.object({
      address: z.string().describe("Address to validate"),
      network: z.enum(["mainnet", "testnet"]).optional().describe("Network to validate against"),
    });
  • Registration of the validateStacksAddressTool in the FastMCP server.
    server.addTool(validateStacksAddressTool);
  • Import statement that brings the validateStacksAddressTool into the index for registration.
      getStacksAccountInfoTool,
      checkSTXBalanceTool,
      getTransactionHistoryTool,
      validateStacksAddressTool
    } from "./stacks_blockchain/accounts/stacks_account.js";
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 describes what the tool does (validation) but doesn't disclose important behavioral traits: whether this is a read-only operation (likely, but not stated), what happens with invalid addresses (returns error? boolean?), whether there are rate limits, or what the output format looks like. For a validation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool 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 communicates the core functionality without waste. It's appropriately sized for a straightforward validation tool and front-loads the essential information. Every word earns its place in this concise formulation.

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 relatively simple validation tool with 2 parameters and 100% schema coverage, the description is adequate but has gaps. Without annotations or output schema, it doesn't describe the return format (boolean? validation details? error messages?) or important behavioral aspects. The description covers the basic purpose but leaves the agent guessing about the tool's complete behavior and output.

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 clearly documented in the schema. The description adds minimal value beyond the schema by mentioning 'Stacks address' (implied by the tool name) and 'specified network' (already clear from the schema's enum). It doesn't provide additional context about address formats, network differences, or validation rules. 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 tool's purpose: 'Validate a Stacks address format and check if it's correctly formatted for the specified network.' It specifies the verb (validate), resource (Stacks address), and scope (format correctness and network-specific validation). However, it doesn't explicitly differentiate from sibling tools like 'get_stacks_account_info' or 'check_stx_balance' which might also involve address validation as part of their 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 context by mentioning 'for the specified network,' suggesting this tool should be used when network-specific address validation is needed. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_stacks_account_info' (which might validate addresses as part of account lookup) or when NOT to use it (e.g., for balance checks). The guidance is present but not comprehensive.

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