Skip to main content
Glama

estimate_operation_cost

Calculate computational costs for Clarity smart contract operations using SIP-012 cost functions to optimize contract performance and resource planning.

Instructions

Estimate the computational cost of specific Clarity operations based on SIP-012 cost functions. Useful for planning contract optimization.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataSizeYesSize of data being processed (e.g., list length, string length)
iterationsNoNumber of iterations for batch operations
operationYesType of operation to estimate

Implementation Reference

  • The complete tool definition including name, description, parameters schema reference, and execute handler function that implements the core logic for estimating operation costs using SIP-012 cost functions.
    export const estimateOperationCostTool: Tool<undefined, typeof CostEstimationScheme> = {
      name: "estimate_operation_cost",
      description: "Estimate the computational cost of specific Clarity operations based on SIP-012 cost functions. Useful for planning contract optimization.",
      parameters: CostEstimationScheme,
      execute: async (args, context) => {
        try {
          await recordTelemetry({ action: "estimate_operation_cost" }, context);
          
          const costs = calculateOperationCost(args.operation, args.dataSize, args.iterations || 1);
          const blockUtilization = calculateBlockUtilization(costs);
          
          return `# Operation Cost Estimation
    
    ## Operation Details
    - **Type**: ${args.operation}
    - **Data Size**: ${args.dataSize.toLocaleString()}
    - **Iterations**: ${args.iterations || 1}
    
    ## Estimated Costs (SIP-012)
    
    ### Resource Consumption
    \`\`\`
    Runtime Cost: ${costs.runtime.toLocaleString()} units
    Read Count: ${costs.readCount} operations
    Write Count: ${costs.writeCount} operations  
    Read Length: ${costs.readLength.toLocaleString()} bytes
    Write Length: ${costs.writeLength.toLocaleString()} bytes
    \`\`\`
    
    ### Block Utilization
    - **Runtime**: ${blockUtilization.runtime.toFixed(4)}% (${costs.runtime.toLocaleString()}/${SIP012_COSTS.limits.runtime.toLocaleString()})
    - **Read Count**: ${blockUtilization.readCount.toFixed(4)}% (${costs.readCount}/${SIP012_COSTS.limits.readCount})
    - **Write Count**: ${blockUtilization.writeCount.toFixed(4)}% (${costs.writeCount}/${SIP012_COSTS.limits.writeCount})
    - **Read Length**: ${blockUtilization.readLength.toFixed(4)}% (${costs.readLength.toLocaleString()}/${SIP012_COSTS.limits.readLength.toLocaleString()})
    - **Write Length**: ${blockUtilization.writeLength.toFixed(4)}% (${costs.writeLength.toLocaleString()}/${SIP012_COSTS.limits.writeLength.toLocaleString()})
    
    ### Performance Analysis
    ${blockUtilization.runtime > 50 ? '⚠️ **High Runtime Usage**: Consider optimization' : '✅ **Runtime**: Within reasonable bounds'}
    ${blockUtilization.readCount > 50 ? '⚠️ **High Read Count**: Consider batching or caching' : '✅ **Read Count**: Efficient database usage'}
    ${blockUtilization.writeCount > 50 ? '⚠️ **High Write Count**: Consider data structure optimization' : '✅ **Write Count**: Efficient storage usage'}
    
    ## Optimization Suggestions
    
    ${getOptimizationSuggestions(args.operation, costs, blockUtilization)}
    
    ## Batch Operation Analysis
    ${args.iterations && args.iterations > 1 ? `
    **Single Operation Cost**: ${Math.round(costs.runtime / args.iterations).toLocaleString()} runtime units
    **Batch Efficiency**: ${(args.iterations > 10 ? 'High' : args.iterations > 5 ? 'Medium' : 'Low')} efficiency gain
    **Recommended Batch Size**: ${getRecommendedBatchSize(args.operation, costs)}
    ` : 'Single operation - consider batching for multiple operations'}
    
    ## SIP-012 Improvements
    ✅ **Enhanced Limits**: 2x more database operations available
    ✅ **Better Costing**: More accurate runtime cost estimation  
    ✅ **Dynamic Storage**: List storage based on actual size
    ✅ **Improved Throughput**: Better block space utilization`;
          
        } catch (error) {
          return `❌ Failed to estimate operation cost: ${error}`;
        }
      },
    };
  • Zod schema defining the input parameters for the estimate_operation_cost tool: operation type, dataSize, and optional iterations.
    const CostEstimationScheme = z.object({
      operation: z.enum([
        "map-read", "map-write", "list-append", "list-filter", "string-concat",
        "arithmetic", "contract-call", "token-transfer", "batch-operation"
      ]).describe("Type of operation to estimate"),
      dataSize: z.number().describe("Size of data being processed (e.g., list length, string length)"),
      iterations: z.number().optional().describe("Number of iterations for batch operations"),
    });
  • Registration of the estimateOperationCostTool in the FastMCP server.
    server.addTool(estimateOperationCostTool);
  • SIP-012 cost constants and block limits used throughout the cost estimation logic.
    const SIP012_COSTS = {
      // Runtime costs (in units)
      runtime: {
        mapGet: 64,
        mapSet: 64,
        mapDelete: 64,
        listAppend: 32,
        listFilter: 64,
        listMap: 64,
        listFold: 64,
        stringConcat: 32,
        arithmetic: 1,
        contractCall: 1000,
        tokenTransfer: 50000,
      },
      
      // Storage costs (per byte)
      storage: {
        read: 1,
        write: 10,
      },
      
      // Block limits (post SIP-012)
      limits: {
        runtime: 5000000000,
        readCount: 15000,
        readLength: 100000000,
        writeCount: 15000,
        writeLength: 15000000,
      }
    };
  • Core helper function that calculates detailed costs for different operations based on SIP-012 metrics, called directly from the tool handler.
    function calculateOperationCost(operation: string, dataSize: number, iterations: number) {
      const baseCosts = SIP012_COSTS.runtime;
      let costs = {
        runtime: 0,
        readCount: 0,
        writeCount: 0,
        readLength: 0,
        writeLength: 0
      };
      
      switch (operation) {
        case "map-read":
          costs.runtime = baseCosts.mapGet * iterations;
          costs.readCount = iterations;
          costs.readLength = dataSize * 40 * iterations;
          break;
          
        case "map-write":
          costs.runtime = baseCosts.mapSet * iterations;
          costs.writeCount = iterations;
          costs.writeLength = dataSize * 40 * iterations;
          break;
          
        case "list-append":
          costs.runtime = baseCosts.listAppend * iterations * Math.log2(dataSize);
          costs.writeCount = iterations;
          costs.writeLength = dataSize * 8 * iterations;
          break;
          
        case "token-transfer":
          costs.runtime = baseCosts.tokenTransfer * iterations;
          costs.readCount = iterations;
          costs.writeCount = iterations * 2;
          costs.readLength = 40 * iterations;
          costs.writeLength = 80 * iterations;
          break;
          
        case "batch-operation":
          const batchEfficiency = Math.min(0.8, Math.log10(iterations) / 2);
          costs.runtime = baseCosts.mapSet * iterations * (1 - batchEfficiency);
          costs.readCount = Math.ceil(iterations / 2);
          costs.writeCount = iterations;
          costs.writeLength = dataSize * iterations;
          break;
          
        default:
          costs.runtime = 1000 * iterations;
      }
      
      return costs;
    }
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 is 'based on SIP-012 cost functions,' which adds some context about the estimation methodology, but it doesn't describe key behavioral traits such as whether this is a read-only operation, what the output format looks like (e.g., cost units, error handling), or any limitations (e.g., accuracy, supported operations beyond the enum). 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with two sentences that directly state the purpose and usage context without unnecessary details. Every sentence earns its place by clarifying the tool's function and utility. However, it could be slightly more structured by explicitly separating purpose from guidelines, but it remains efficient and easy to parse.

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 covers the basic purpose and hints at usage but lacks details on behavioral aspects like output format, error cases, or integration with sibling tools. Without annotations or an output schema, the description should do more to compensate, but it falls short of being fully complete for effective agent 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 clear documentation for each parameter (e.g., 'dataSize' as 'Size of data being processed,' 'operation' with an enum list). The description doesn't add any additional semantic meaning beyond what's already in the schema, such as explaining how 'dataSize' and 'iterations' interact or providing examples of cost estimation outputs. Since the schema does the heavy lifting, 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: 'Estimate the computational cost of specific Clarity operations based on SIP-012 cost functions.' It specifies the verb ('estimate'), resource ('computational cost'), and domain ('Clarity operations'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'analyze_contract_performance' or 'generate_optimization_recommendations', which might have overlapping optimization-related purposes.

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 provides implied usage guidance with 'Useful for planning contract optimization,' suggesting it should be used during optimization planning phases. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'analyze_contract_performance' for post-execution analysis or 'generate_optimization_recommendations' for actionable advice), nor does it mention any exclusions 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.

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