Skip to main content
Glama

generate_clarinet_project

Create a complete Clarinet project with proper structure, configuration, and starter smart contracts for Stacks blockchain development using predefined templates.

Instructions

Generate a complete Clarinet project setup with proper structure, configuration, and starter contracts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectNameYesName of the Clarinet project to create
projectPathNoPath where to create the project (default: current directory)
templateNoProject template to use

Implementation Reference

  • The main handler implementation defining the 'generate_clarinet_project' tool. The execute function generates a comprehensive Markdown guide for setting up a new Clarinet project including structure, configurations, templates, and commands.
    export const generateClarinetsProjectTool: Tool<undefined, typeof ClarinetsInitScheme> = {
      name: "generate_clarinet_project",
      description: "Generate a complete Clarinet project setup with proper structure, configuration, and starter contracts.",
      parameters: ClarinetsInitScheme,
      execute: async (args, context) => {
        try {
          await recordTelemetry({ action: "generate_clarinet_project" }, context);
          
          const projectName = args.projectName;
          const projectPath = args.projectPath || './';
          const template = args.template || 'empty';
          
          return `# Clarinet Project Setup Guide
    
    ## Project: ${projectName}
    
    ### 1. Initialize Clarinet Project
    
    \`\`\`bash
    # Create new Clarinet project
    clarinet new ${projectName}
    cd ${projectName}
    
    # Verify Clarinet installation
    clarinet --version
    \`\`\`
    
    ### 2. Project Structure
    
    After initialization, your project will have this structure:
    
    \`\`\`
    ${projectName}/
    ├── Clarinet.toml           # Main project configuration
    ├── settings/               # Network-specific settings
    │   ├── Devnet.toml
    │   ├── Testnet.toml
    │   └── Mainnet.toml
    ├── contracts/              # Clarity contracts
    ├── tests/                  # TypeScript/JavaScript tests
    ├── deployments/            # Deployment plans
    └── .gitignore
    \`\`\`
    
    ### 3. Clarinet.toml Configuration
    
    \`\`\`toml
    [project]
    name = "${projectName}"
    authors = []
    description = ""
    telemetry = true
    cache_dir = "./.clarinet/cache"
    requirements = []
    
    [contracts.${projectName}]
    path = "contracts/${projectName}.clar"
    clarity_version = 2
    epoch = "2.4"
    
    [repl]
    costs_version = 2
    parser_version = 2
    
    [repl.analysis]
    passes = ["check_checker"]
    
    [repl.analysis.check_checker]
    strict = false
    trusted_sender = false
    trusted_caller = false
    callee_filter = false
    \`\`\`
    
    ### 4. Network Configurations
    
    #### Devnet Settings (\`settings/Devnet.toml\`)
    \`\`\`toml
    [network]
    name = "devnet"
    deployment_fee_rate = 10
    
    [accounts.deployer]
    mnemonic = "twice kind fence tip hidden tilt action fragile skin nothing glory cousin green tomorrow spring wrist shed math olympic multiply hip blue scout claw"
    balance = 100000000000000
    
    [accounts.wallet_1] 
    mnemonic = "sell invite acquire kitten bamboo drastic jelly vivid peace spawn twice guilt pave pen trash pretty park cube fragile unaware remain midnight betray rebuild"
    balance = 100000000000000
    
    [accounts.wallet_2]
    mnemonic = "hold excess usual excess ring elephant install account glad dry fragile donkey gaze humble truck breeze nation gasp vacuum limb head keep delay hospital"
    balance = 100000000000000
    \`\`\`
    
    ### 5. ${template.charAt(0).toUpperCase() + template.slice(1)} Template Implementation
    
    ${getTemplateImplementation(template, projectName)}
    
    ### 6. Essential Development Commands
    
    \`\`\`bash
    # Start Clarinet console for interactive development
    clarinet console
    
    # Run tests
    clarinet test
    
    # Check contract syntax
    clarinet check
    
    # Generate deployment plan
    clarinet deployments generate --devnet
    
    # Deploy to devnet
    clarinet deployments apply --devnet
    
    # Start local devnet (if needed)
    clarinet integrate
    
    # Format contract code
    clarinet fmt
    \`\`\`
    
    ### 7. Test Setup
    
    Create a basic test file: \`tests/${projectName}_test.ts\`
    
    \`\`\`typescript
    import { Clarinet, Tx, Chain, Account, types } from 'https://deno.land/x/clarinet@v1.0.0/index.ts';
    import { assertEquals } from 'https://deno.land/std@0.90.0/testing/asserts.ts';
    
    Clarinet.test({
        name: "Ensure that basic functionality works",
        async fn(chain: Chain, accounts: Map<string, Account>) {
            const deployer = accounts.get("deployer")!;
            const wallet1 = accounts.get("wallet_1")!;
            
            let block = chain.mineBlock([
                // Add your test transactions here
            ]);
            
            assertEquals(block.receipts.length, 0);
            assertEquals(block.height, 2);
        },
    });
    \`\`\`
    
    ### 8. VS Code Integration
    
    Create \`.vscode/settings.json\` for better development experience:
    
    \`\`\`json
    {
        "clarinet.enable": true,
        "editor.formatOnSave": true,
        "[clarity]": {
            "editor.tabSize": 2,
            "editor.insertSpaces": true
        },
        "files.associations": {
            "*.clar": "clarity"
        }
    }
    \`\`\`
    
    ### 9. Git Setup
    
    Add to \`.gitignore\`:
    
    \`\`\`
    # Clarinet
    .clarinet/
    costs-reports.json
    
    # Logs
    *.log
    npm-debug.log*
    
    # Dependencies
    node_modules/
    
    # IDE
    .vscode/
    .idea/
    \`\`\`
    
    ### 10. Next Steps
    
    1. **Add Contracts**: Place your Clarity contracts in \`contracts/\`
    2. **Write Tests**: Create comprehensive tests in \`tests/\`
    3. **Configure Networks**: Update settings for testnet/mainnet
    4. **Add Dependencies**: Use \`requirements\` in Clarinet.toml for contract dependencies
    5. **CI/CD**: Set up GitHub Actions for automated testing
    
    ### 11. Useful Development Tools
    
    \`\`\`bash
    # Generate contract scaffold
    clarinet contract new my-contract
    
    # Add existing contract
    clarinet contract add my-contract contracts/my-contract.clar
    
    # Interactive Clarinet console commands
    clarinet console
    > (contract-call? .${projectName} some-function)
    > ::get_costs
    > ::get_contracts_by_trait
    \`\`\`
    
    ### 12. Performance Optimization
    
    Use these Clarinet commands for performance analysis:
    
    \`\`\`bash
    # Generate cost analysis
    clarinet test --costs
    
    # Check contract coverage
    clarinet test --coverage
    
    # Analyze contract size
    clarinet check --decode
    \`\`\`
    
    Your Clarinet project is now ready for development! Use the MCP tools like \`generate_clarity_contract\` and \`generate_contract_tests\` to add functionality to your project.`;
          
        } catch (error) {
          return `❌ Failed to generate Clarinet project: ${error}`;
        }
      },
    };
  • Zod schema defining the input parameters for the generate_clarinet_project tool: projectName (required), projectPath (optional), template (optional enum).
    const ClarinetsInitScheme = z.object({
      projectName: z.string().describe("Name of the Clarinet project to create"),
      projectPath: z.string().optional().describe("Path where to create the project (default: current directory)"),
      template: z.enum(["counter", "nft", "fungible-token", "empty"]).optional().describe("Project template to use"),
    });
  • Registration of the generate_clarinet_project tool in the central tools index by adding it to the FastMCP server.
    server.addTool(generateClarinetsProjectTool);
  • Import of the generateClarinetsProjectTool from its implementation file, enabling registration.
    import {
      generateClarinetsProjectTool,
      generateClarityContractTool,
      generateContractTestsTool,
      configureClarinetsProjectTool
    } from "./stacks_blockchain/development/clarinet_project.js";
  • Helper function that generates template-specific Clarity contract code based on the chosen project template (counter, nft, etc.). Used within the handler.
    function getTemplateImplementation(template: string, projectName: string): string {
      switch (template) {
        case 'counter':
          return `\`\`\`clarity
    ;; Counter Template Implementation
    (define-data-var counter uint u0)
    
    (define-read-only (get-counter)
      (var-get counter)
    )
    
    (define-public (increment)
      (ok (var-set counter (+ (var-get counter) u1)))
    )
    
    (define-public (decrement)
      (ok (var-set counter (- (var-get counter) u1)))
    )
    \`\`\``;
    
        case 'nft':
          return `\`\`\`clarity
    ;; SIP-009 NFT Template Implementation
    (use-trait sip009-trait 'SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait.nft-trait)
    
    (define-non-fungible-token ${projectName} uint)
    (define-data-var last-token-id uint u0)
    
    (define-public (mint (recipient principal))
      (let ((token-id (+ (var-get last-token-id) u1)))
        (var-set last-token-id token-id)
        (nft-mint? ${projectName} token-id recipient)
      )
    )
    
    (define-public (transfer (token-id uint) (sender principal) (recipient principal))
      (begin
        (asserts! (is-eq tx-sender sender) (err u403))
        (nft-transfer? ${projectName} token-id sender recipient)
      )
    )
    \`\`\``;
    
        case 'fungible-token':
          return `\`\`\`clarity
    ;; SIP-010 Fungible Token Template Implementation
    (use-trait sip010-trait 'SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard.sip-010-trait)
    
    (define-fungible-token ${projectName})
    
    (define-public (transfer (amount uint) (sender principal) (recipient principal) (memo (optional (buff 34))))
      (begin
        (asserts! (is-eq tx-sender sender) (err u403))
        (ft-transfer? ${projectName} amount sender recipient)
      )
    )
    
    (define-public (mint (amount uint) (recipient principal))
      (ft-mint? ${projectName} amount recipient)
    )
    \`\`\``;
    
        default:
          return `\`\`\`clarity
    ;; Empty Template - Add your contract logic here
    (define-constant contract-owner tx-sender)
    
    (define-public (hello-world)
      (ok "Hello, Stacks!")
    )
    \`\`\``;
      }
    }
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 generating a 'complete setup' but doesn't specify whether this creates files on disk, requires write permissions, overwrites existing projects, or includes dependencies. For a tool that likely performs file system operations, this is a significant gap in transparency about its behavior and potential side effects.

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 a single, efficient sentence that front-loads the core action ('Generate a complete Clarinet project setup') and specifies key aspects (structure, configuration, starter contracts). There's no wasted verbiage, but it could be slightly more structured by separating setup components or adding brief context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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

Given the complexity of generating a project setup (likely involving file creation and configuration), the description is incomplete. No annotations cover safety or behavior, and there's no output schema to clarify what's returned (e.g., success status, project path). The description doesn't compensate for these gaps, leaving the agent with insufficient information to understand the tool's full impact and results.

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%, so the schema already documents all three parameters (projectName, projectPath, template) with descriptions and enum values. The description adds no additional semantic context beyond implying that parameters relate to project generation. This meets the baseline for high schema coverage but doesn't enhance understanding of how parameters interact or affect the outcome.

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: 'Generate a complete Clarinet project setup with proper structure, configuration, and starter contracts.' It specifies the verb ('Generate') and resource ('Clarinet project'), including key components like structure, configuration, and contracts. However, it doesn't explicitly differentiate from sibling tools like 'configure_clarinet_project' or 'build_clarity_smart_contract', which prevents a perfect score.

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. It doesn't mention prerequisites (e.g., needing Clarinet installed), compare to similar tools like 'configure_clarinet_project' (which might modify existing projects), or specify use cases (e.g., starting a new project from scratch). This lack of context leaves the agent guessing about appropriate usage scenarios.

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