SuperAPI AI Directory

ARBuilder

Code generator for Arbitrum: Stylus smart contracts, SDK bridging, full-stack dApps and Orbit chain deployment, backed by RAG over Arbitrum documentation.

Open website

About this tool

ARBuilder is an AI-driven development assistant for the Arbitrum ecosystem developed by Quantum3-Labs, turning natural language prompts into ready-to-use on-chain code and deployment scripts.

[Purpose] ARBuilder mainly serves developers building applications on Arbitrum, covering four development paths: Stylus smart contracts (Rust), cross-chain bridging and messaging implementations with the Arbitrum SDK, full-stack dApp scaffolding, and deployment and management of Orbit chains. It provides context-aware code generation through retrieval-augmented generation (RAG).

[Main Capabilities] The MCP server exposes 19 tools, 11 resources, and 5 prompt templates for integration with AI IDEs such as Cursor/VS Code. The tools are divided into four groups:

  1. Stylus development (6 tools): context search, code generation, test generation, Q&A assistant, workflow guidance, code validation. Code generation is based on built-in templates (Counter, VendingMachine, SimpleERC20, AccessControl, DeFiVault, StakingRewards, NftRegistry, 7 in total), using customized verified working templates rather than generating from scratch to improve compilability. Test generation covers unit, integration, and fuzz testing. Code validation is based on Docker's cargo check, with up to 3 automatic fixes and Stylus-specific error guidance. Full support for Stylus SDK 0.10.0 (alloy 1.0.1, Rust 1.91.0, self.vm() API).
  2. Arbitrum SDK bridging and messaging (3 tools): ETH bridging (L1 <-> L2 deposits and withdrawals), ERC20 bridging (including gateway approval), L1 -> L3 bridging (bridging directly from L1 to an Orbit chain via double retryable), cross-chain messaging (L1 -> L2 retryable tickets, L2 -> L1 messages), message status tracking, and withdrawal claiming.
  3. Full-stack dApp building (5 tools): backend generation (NestJS or Express, integrated with viem/wagmi), frontend generation (Next.js 14 + wagmi v2 + RainbowKit v2 + DaisyUI), indexer generation (The Graph subgraph), oracle integration (Chainlink price feeds, VRF, Automation, Functions), overall orchestration (monorepo structure scaffolding). Supports automatic extraction of ABIs from Stylus Rust code and injection into the backend/frontend; indexer schema and mappings, frontend hooks, and backend routes are all generated based on the ABI; compilation validation uses a Docker-based cargo check loop for automatic fixes; generates executable setup.sh, deploy.sh, and start.sh scripts; environment variables are centrally standardized (PORT 3001, CORS, BACKEND_URL).
  4. Orbit chain integration (5 tools plus 9 TypeScript templates): tools such as generate_orbit_config, generate_orbit_deployment, generate_validator_setup, ask_orbit, orchestrate_orbit; templates cover chain configuration, deploying a Rollup, deploying a token bridge, custom Gas tokens, validator management, governance, node configuration, AnyTrust configuration, and orchestration. Based on @arbitrum/chain-sdk ^0.25.0 and viem ^1.20.0, supports prepareChainConfig(), createRollup(), createTokenBridge(), prepareNodeConfig(). Deployment output is persisted to deployment.json, and subsequent scripts (token bridge, node configuration) are automatically chained; crash-resistant deployment saves deployment.json before obtaining the receipt; custom Gas tokens generate approve-token.ts with the correct RollupCreator address and ERC-20 deployment guidance. Docker uses offchainlabs/nitro-node:v3.9.4-7f582c3 with bind mounts (./data/arbitrum), not user: root. Node configuration post-processing restores masked private keys, disables the staker in single-key scenarios, and fixes the DAS URL dual-portIssues; Wasm root checking via --validation.wasm.allowed-wasm-module-roots prevents startup crash loops; AnyTrust uses the nitro-node image's datool keygen for BLS key generation. Supports Rollup and AnyTrust chains, custom Gas tokens, validator/batch poster management, and full project scaffolding.

[How to Use] Two approaches:

  1. Hosted service (zero setup): register at arbuilder.app to get an API key, add it to the MCP configuration, and you're done. The free tier offers 100 API calls per day, requires no local Python environment, and is always in sync with the latest Stylus SDK patterns. The hosted service also provides an OpenAI-compatible Chat Completions API (model arbbuilder-chat, based on openai/gpt-oss-120b via OpenRouter), supporting streaming and non-streaming, native function calling, chain-of-thought pass-through (reasoning_content), stateless conversations, and automatic length continuation; limits are 6 ReAct iterations / a 200k token single-turn budget / a 32k character cap on tool results; it does not include the 4 large project scaffolding tools (generate_backend, generate_frontend, orchestrate_dapp, orchestrate_orbit), which must be invoked directly via /api/v1/tools/<name> or MCP.
  2. Self-hosted (full control): run locally, bring your own API key, no rate limits. Requires creating a Conda environment, configuring environment variables (copy the example environment file and fill in credentials), generating the ChromaDB vector database locally (not included in the repository due to binary compatibility issues), and verifying that the MCP server starts. The repository already includes the raw data (data/raw/: documentation pages + curated GitHub repositories) and processed chunks (data/processed/). If you need to re-scrape the latest documentation and code, you can optionally install playwright. Configure your IDE: write the MCP configuration into Cursor's ~/.cursor/mcp.json or Claude Desktop 's claude_desktop_config.json, then restart the IDE to let the AI assistant call ARBuilder tools. Typical example prompts: "Generate an ERC20 token contract in Stylus", "How do I deploy a contract to Arbitrum Sepolia?", "Write tests for my counter contract". When generating Stylus contracts, you can pass target_version to output code for a specified SDK version.

[Knowledge Base and Data Sources] sources.json is the single source of truth for both the local Python pipeline and the hosted CF Worker collection, containing 84 curated sources (53 documentation pages + 31 GitHub repositories), divided into 4 milestones: Stylus contracts/projects (17 docs + 19 repos), Arbitrum SDK (6 docs + 5 repos), full-stack dApp building (30 docs + 11 repos), Orbit SDK (5 Python MCP tools + 9 TypeScript templates). Data curation policy: do not use aggregate lists (such as awesome-stylus) to avoid outdated code, do not accept unverified community submissions, code repositories must compile with stylus-sdk >= 0.8.0, SDK versions are recorded per repository, and Stylus repositories are uniformly forked to ARBuilder-Forks for traceability and resistance to upstream deletion. A multi-version strategy is adopted: branching by version (e.g., main corresponds to 0.10.0, v0.9.0 corresponds to the original version), branch-aware scraping, and version-aware generation and retrieval. The pipeline implements 3 layers of filtering to remove junk data (vendored crates, auto-generated TypeChain files, hex bytecode, lock files, cross-repository duplicates), see docs/DATA_CURATION_POLICY.md for details. The hosted service has a built-in collection pipeline that runs automatically via cron every 6 hours, and can also be triggered manually at /admin; it uses a synchronous path by source size (documentation and repositories with <=30 files) and an asynchronous path (repositories with >30 files, processed in batches via CF Queue).

[TransparencyDegrees and Interfaces】 arbuilder.app/transparency publicly displays the included sources, code templates, and statistical information. Public API (no authentication required): GET /api/public/sources, GET /api/public/templates, GET /api/public/templates?code=true. The internal direct API is located at /api/v1/tools/*, for internal testing only, requires providing AUTH_SECRET in the Authorization header, is not for public use, and is called by CI/CD and internal validation scripts.

【Limitations and Notes】 The MCP server provides command knowledge rather than command execution; users control what runs on their local machine, avoiding the security risks of remote execution. The hosted free tier allows 100 calls per day. Self-hosting requires configuring your own API key and local vector database. The above is the information explicitly provided in the materials; content not explained in the materials, such as specific pricing, deployment scale, and performance metrics, is not provided for now.