I’ve been building developer tools long enough to recognize when an ecosystem is missing one.
If you’ve worked with Kubernetes, you probably remember what it was like before kubectl matured — before the CLI caught up to the platform’s capabilities. You could do everything through the API, technically. But “technically possible” and “practical for daily development” are very different things.
Canton Network is at that stage right now. The protocol is production-ready. Major financial institutions are running real workloads. But the developer experience for building applications on Canton still has rough edges — especially in the lifecycle between writing your first Daml contract and deploying it to a running environment.
Cantool is my attempt to close that gap.
What It Is
Cantool is a Go CLI that covers the Canton application development lifecycle: project scaffolding, Daml compilation, testing, local sandbox management, environment configuration, and — this part is new for the Canton ecosystem — an MCP server for AI-assisted development.
If you’ve used create-react-app to scaffold a project, forge to manage a Foundry workflow, or wp scaffold for WordPress, you know the shape. A single binary that handles the daily development loop — from init to build to test to dev — without requiring you to stitch together three different tools to do it.
# Create a new Canton project
cantool init my-app --template basic
cd my-app
# Check your environment
cantool status
# Manage environment profiles
cantool env add local --host localhost --ledger-port 5011
cantool env use localIt ships as a single static binary — no JVM, no runtime dependencies for core commands. Download it, put it on your path, and you’re working.
The Development Lifecycle Problem
Canton’s existing tools each do their job well. The Daml SDK provides dpm for package compilation and dependency management. The Canton console handles node administration. DevKit (another community project) manages local environment lifecycle. The Ledger and JSON APIs provide full programmatic access.
What’s missing is a tool that ties together the application development workflow — the loop a developer runs through dozens of times a day when building Canton applications. Start a project. Configure your environment. Build your Daml. Run your tests. Spin up a local sandbox. Iterate.
That workflow currently spans multiple tools with different invocation patterns, different configuration models, and different output formats. Cantool unifies the common path through a consistent interface.
Complementary, Not Competitive
This distinction has been central to the grant proposal process, and it’s worth being explicit about: Cantool doesn’t reimplement what existing tools already do. It delegates.
When you run cantool build, the tool delegates to dpm build under the hood and prints an attribution line so you always know what’s actually running. Same for cantool test and cantool dev. These convenience commands are provided through a plugin that you explicitly enable — they’re not the default, and they’re transparent about what they’re wrapping.
# cantool.yaml - project configuration
version: "1"
project:
name: my-app
sdk-version: "3.4.11"
parties:
- name: Alice
display: "Alice Corp"
- name: Bob
display: "Bob Trading"
environments:
local:
host: localhost
ledger-port: 5011
json-api-port: 7575
plugins:
convenience:
enabled: trueThe greenfield functionality — the parts that don’t exist elsewhere — is where Cantool’s core value lives: project scaffolding with opinionated templates, multi-environment configuration profiles, structured error codes with fix suggestions, and the MCP server.
The MCP Server
This is the feature I’m most excited about, and it’s the one that’s hardest to explain if you haven’t used AI-assisted development tools.
Cantool ships with a built-in MCP (Model Context Protocol) server. When you run cantool mcp serve, it exposes Canton operations — querying contracts, listing parties, checking ledger status, allocating parties, uploading DAR packages — as structured tools that AI assistants can invoke.
{
"mcpServers": {
"cantool": {
"command": "cantool",
"args": ["mcp", "serve"]
}
}
}Drop that configuration into Claude Code, Cursor, or any MCP-aware tool, and your AI assistant can interact with your Canton development environment directly. It can query active contracts, inspect party topology, upload packages — all through the same structured interface that Cantool uses internally.
For Canton developers, this means you can describe what you want in natural language and have the assistant execute it against your actual ledger. For the Canton ecosystem, it means AI-assisted development works out of the box rather than requiring each developer to build their own integration.
The Plugin System
Cantool is designed to be extensible. The convenience commands that wrap dpm are themselves implemented as a built-in plugin. External plugins communicate via JSON-RPC over stdin/stdout — a standard, language-agnostic interface that lets the community extend Cantool without forking it.
This matters for the longer term. As the Canton ecosystem grows, different teams will need different workflows. A plugin architecture means Cantool can support those workflows without becoming a monolith that tries to do everything. Given the number of tools written in Go in the Canton ecosystem, this is a system itself that can be abstracted to provide extensibility for those tools as well!
Why Go
A CLI should be fast, self-contained, and easy to distribute. Go gives me all three. Single static binary, cross-platform builds from one CI pipeline, and a standard library that handles gRPC and HTTP natively. Cantool uses Cobra — the same CLI framework behind kubectl and gh — so the command structure will feel familiar to most developers.
Go also aligns with where Canton infrastructure tooling is heading. Several Canton-adjacent projects are already in Go, and the infrastructure-layer developer community is comfortable with it.
The Canton Dev Fund
Cantool is currently under review as a Canton Development Fund proposal (PR #77). The dev fund is a milestone-based grant system administered through the Canton Foundation — proposals go through community review, and funding is released as completed milestones are verified.
The proposal has been through significant refinement over the past month — several revisions narrowing scope, clarifying the relationship with existing tools like DevKit and the Daml Code Assistant, and tightening the milestone structure. That process has been rigorous and genuinely valuable. The feedback pushed me to be precise about what Cantool both does and doesn’t do.
The tool is better for it.
If you’re interested in the proposal details, the discussion, or the milestone structure, the PR is public on the canton-dev-fund repository. Feedback from Canton developers — especially around which operations you’d most want in a CLI — is exactly the kind of input that makes the tool better.
What’s Next
Thursday’s post takes a different angle — I’ll talk about my journey from cross-chain DeFi infrastructure to Canton, and why I chose to build here after years in the broader space.
This is the context behind the code.
I’ll have more to share about Cantool’s roadmap and the broader Displace Technologies vision in the coming weeks.