Skip to main content
Glama

foundry_project

Manage Foundry project lifecycle operations including setup, dependencies, compilation, and gas optimization for smart contract development.

Instructions

Manage Foundry project lifecycle operations.

OPERATIONS:

  • init: Initialize new Foundry project with templates

  • install: Install git submodule dependency (e.g., forge-std)

  • update: Update all dependencies

  • remove: Remove a dependency

  • clean: Clean build artifacts

  • build: Compile contracts with optimization options

  • fmt: Format Solidity code

  • inspect: Inspect contract artifacts (ABI, bytecode, storage-layout)

  • get_artifacts: Retrieve compiled artifacts

  • snapshot: Create gas usage snapshot for optimization

USE FOR: Project setup, dependencies, compilation, and gas optimization.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationYesProject operation to perform
directoryNoAbsolute path to Foundry project directory (required for all operations except init which creates it)
templateNoProject template (for init)
dependencyNoDependency name (for install/remove)
optimizeNoEnable optimizer (for build)
optimizerRunsNoOptimizer runs (for build)
viaIrNoUse IR pipeline (for build)
contractNameNoContract name (for inspect/get_artifacts)
fieldNoInspection field (for inspect)

Implementation Reference

  • Primary handler function for the 'foundry_project' tool. Dispatches to specific Foundry operations (init, build, test, etc.) based on the 'operation' argument.
    export async function foundryProjectManage(args: {
      operation: 'init' | 'install' | 'update' | 'remove' | 'clean' | 'build' | 'fmt' | 'inspect' | 'get_artifacts' | 'snapshot';
      // Init-specific
      directory?: string;
      template?: string;
      // Install/Remove-specific
      dependency?: string;
      // Build-specific
      optimize?: boolean;
      optimizerRuns?: number;
      viaIr?: boolean;
      // Inspect-specific
      contractName?: string;
      field?: 'abi' | 'bytecode' | 'assembly' | 'storage-layout';
    }): Promise<ToolResult> {
      try {
        logger.info('Foundry project operation', { operation: args.operation });
    
        switch (args.operation) {
          case 'init':
            return await foundryTools.foundryInit({
              directory: args.directory,
              template: args.template as 'basic' | 'advanced' | undefined,
            });
    
          case 'install':
            return await foundryTools.foundryInstall({ dependency: args.dependency! });
    
          case 'update':
            return await foundryTools.foundryUpdate();
    
          case 'remove':
            return await foundryTools.foundryRemove({ dependency: args.dependency! });
    
          case 'clean':
            return await foundryTools.foundryClean({ directory: args.directory });
    
          case 'build':
            return await foundryTools.foundryBuild({
              optimize: args.optimize,
              optimizerRuns: args.optimizerRuns,
              viaIr: args.viaIr,
              directory: args.directory,
            });
    
          case 'fmt':
            return await foundryTools.foundryFmt({ directory: args.directory });
    
          case 'inspect':
            return await foundryTools.foundryInspect({
              contractName: args.contractName!,
              field: args.field || 'abi',
            });
    
          case 'get_artifacts':
            return await foundryTools.foundryGetArtifacts({ contractName: args.contractName, directory: args.directory });
    
          case 'snapshot':
            return await foundryTools.foundrySnapshot({ directory: args.directory });
    
          default:
            throw new Error(`Unknown operation: ${args.operation}`);
        }
      } catch (error) {
        logger.error('Foundry project operation failed', { operation: args.operation, error });
        return {
          success: false,
          error: error instanceof Error ? error.message : 'Unknown error',
        };
      }
    }
  • Tool definition object for 'foundry_project' including name, description, and inputSchema for validation.
      {
        name: 'foundry_project',
        description: `Manage Foundry project lifecycle operations.
    
    OPERATIONS:
    - init: Initialize new Foundry project with templates
    - install: Install git submodule dependency (e.g., forge-std)
    - update: Update all dependencies
    - remove: Remove a dependency
    - clean: Clean build artifacts
    - build: Compile contracts with optimization options
    - fmt: Format Solidity code
    - inspect: Inspect contract artifacts (ABI, bytecode, storage-layout)
    - get_artifacts: Retrieve compiled artifacts
    - snapshot: Create gas usage snapshot for optimization
    
    USE FOR: Project setup, dependencies, compilation, and gas optimization.`,
        inputSchema: {
          type: 'object' as const,
          properties: {
            operation: {
              type: 'string',
              enum: ['init', 'install', 'update', 'remove', 'clean', 'build', 'fmt', 'inspect', 'get_artifacts', 'snapshot'],
              description: 'Project operation to perform',
            },
            directory: { type: 'string', description: 'Absolute path to Foundry project directory (required for all operations except init which creates it)' },
            template: { type: 'string', description: 'Project template (for init)' },
            dependency: { type: 'string', description: 'Dependency name (for install/remove)' },
            optimize: { type: 'boolean', description: 'Enable optimizer (for build)' },
            optimizerRuns: { type: 'number', description: 'Optimizer runs (for build)' },
            viaIr: { type: 'boolean', description: 'Use IR pipeline (for build)' },
            contractName: { type: 'string', description: 'Contract name (for inspect/get_artifacts)' },
            field: {
              type: 'string',
              enum: ['abi', 'bytecode', 'assembly', 'storage-layout'],
              description: 'Inspection field (for inspect)',
            },
          },
          required: ['operation'],
        },
      },
  • src/index.ts:653-655 (registration)
    Tool registration in the main request handler switch statement, mapping 'foundry_project' calls to the foundryProjectManage handler.
    case 'foundry_project':
      result = await foundryProjectManage(args as any);
      break;
  • Example helper function foundryInit called by the main handler for 'init' operation. Other operations have similar helpers in this file.
    export async function foundryInit(args: {
      directory?: string;
      networks?: Array<'mainnet' | 'testnet' | 'previewnet' | 'local'>;
      solidity?: string;
      template?: 'basic' | 'advanced';
    }): Promise<ToolResult> {
      try {
        const directory = args.directory || process.cwd();
        const networks = args.networks || ['testnet', 'local'];
        const solidity = args.solidity || '0.8.20';
    
        logger.info('Initializing Foundry project', { directory, networks, solidity });
    
        // Create directory if it doesn't exist
        await fs.mkdir(directory, { recursive: true });
    
        // Create directory structure
        await fs.mkdir(path.join(directory, 'src'), { recursive: true });
        await fs.mkdir(path.join(directory, 'test'), { recursive: true });
        await fs.mkdir(path.join(directory, 'script'), { recursive: true });
        await fs.mkdir(path.join(directory, 'lib'), { recursive: true });
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by listing all operations and their purposes, but doesn't disclose important behavioral traits like whether operations are read-only vs. destructive, permission requirements, rate limits, or error handling. The description adds operational context but lacks safety and performance information.

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 well-structured with clear sections (overview, operations list, usage context) and every sentence earns its place. It's appropriately sized for a multi-operation tool. Minor improvement could be made by front-loading the most critical information more prominently, but overall it's efficient and organized.

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 complexity (10 operations, 9 parameters) and absence of both annotations and output schema, the description provides good operational coverage but has significant gaps. It explains what each operation does but doesn't describe return values, error conditions, or behavioral constraints. For a multi-operation tool with no structured safety information, this is adequate but incomplete.

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?

With 100% schema description coverage, the schema already documents all 9 parameters thoroughly. The description adds value by mapping operations to their required parameters (e.g., 'template for init', 'dependency for install/remove'), but doesn't provide additional semantic context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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 tool's purpose as 'Manage Foundry project lifecycle operations' and provides a comprehensive list of 10 specific operations with distinct verbs and resources. It effectively distinguishes this tool from siblings like 'foundry_contract' or 'hardhat_project' by focusing on project-level operations rather than contract-specific or alternative framework tasks.

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 'USE FOR' section explicitly states the contexts for using this tool: 'Project setup, dependencies, compilation, and gas optimization.' This provides clear guidance on when to use it. However, it doesn't specify when NOT to use it or name specific alternative tools for overlapping functionality, preventing a perfect score.

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/justmert/hashpilot'

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