mtb

mtb (Make the Bed)

mtb is an MCP server that intends to help agents and engineers look before they leap by using the Socratic method to help users ask the right questions when building software and nudge them to use existing battle-tested solutions so the focus can remain on solving novel problems.

• consult: Push back on new features with structured questions before any code gets written
• stats: Show complexity scores so users can weigh changes against future maintenance costs
• deps: Know what's already in your project before adding more
• checklist: Evaluate operational readiness before calling a project "done"

In a Calvin and Hobbes strip, Calvin's mom tells him to make his bed. Rather than just do it, he spends the entire day building a robot to make the bed for him. The robot doesn't work, the bed never gets made, and Calvin is more exhausted than if he'd just done it himself.

Most of the energy that goes into software is spent on debugging and maintenance. Metrics such as cyclomatic complexity and COCOMO are the subject of much debate but they do give engineers a rough idea of how much it would have cost to build and therefore maintain the software on which they are working.

AI agents will happily generate a bug-filled JSON parser from scratch when you already have three in your dependencies, or add a new HTTP client library when one is sitting right there in your lock file. And, if you ask it to build a rocketship when a perfectly cromulent open source rocketship is there for the taking, AI will happily help you build a new one.

The hope is that, rather than fixing bugs or going down rabbit holes in bespoke implementations, mtb can help agents and engineers focus on the actual problem they are trying to solve: making the bed, and externalize some of the maintenance costs which can be massive for software.

Demonstration

Without mtb, AI agents enthusiastically say "Great idea!" and start scaffolding projects immediately — database schemas, tech stacks, timelines, and all. With mtb, the agent stops and asks hard questions first.

Each example below shows the same prompt sent to Claude Opus 4.6, with and without mtb:

Tools

These tools are intended for use by AI agents.

consult

Get a structured consultation before implementing a new feature or adding a dependency. Combines GitHub search and dependency scanning with a 5 whys framework to actively push back and force deeper thinking about the actual problem before any code gets written.

Parameters:

• problem - what the user wants to build or the problem they want to solve
• path - project directory to scan for existing dependencies (optional)
• language - filter GitHub search by programming language (optional)

Example: "I'd like to make a production-ready tool that recursively counts words in files and supports all languages"

mtb pushes back — and rightly so. Before writing any code, the agent presents these questions:

1. What's the actual problem you're trying to solve? "Count words in files" is a solution, not a problem. What's driving this? Documentation metrics? Codebase analysis? Something else?
2. Is this truly novel? wc -w already recursively counts words (find . -type f -exec wc -w {} +). Tools like tokei and scc do sophisticated file analysis across languages. What would your tool do that these don't?
3. Is there something already in your stack that could be extended? Rather than building from scratch, could an existing tool or script cover this?
4. What's the maintenance cost? "Supports all languages" is a huge surface area — word boundaries differ across CJK, Thai, Arabic, etc. Are you prepared to maintain Unicode segmentation logic long-term?
5. Who maintains this when requirements change? If this needs to be "production-ready," who owns it after v1?

These aren't meant to block you — they're meant to make sure you're building the right thing.

checklist

Evaluate a project's operational readiness. After shipping code, use this to check whether CI, monitoring, on-call, security, deployment, and documentation concerns have been addressed.

Parameters:

• project - description of the project being evaluated

The checklist covers:

1. Automated tests / CI — regression prevention and standards enforcement
2. Monitoring — health checks, metrics, and alerts
3. On-call coverage / SLAs — response time expectations and escalation
4. Security audit / automated scans — vulnerability detection and isolation
5. Deployment pipeline / CD — promotion to test and production environments
6. Documentation / runbooks — onboarding, extension, and operational procedures

stats

Analyzes code in a directory using scc. Returns lines of code, comments, blanks, complexity, and COCOMO cost estimates per language.

Parameters:

• path - directory or file to analyze
• cocomo - include COCOMO cost estimates (default: true)
• complexity - include complexity metrics (default: true)
• exclude_dir - directories to exclude from analysis
• exclude_ext - file extensions to exclude (e.g. min.js)
• include_ext - only include these file extensions

deps

Scans a directory for dependencies using Syft. Returns all detected packages with name, version, type, and language. Supports 40+ ecosystems including npm, pip, go modules, cargo, maven, gems, and more.

Parameters:

• path - directory to scan
• details - include line count and complexity per dependency (default: false)

Install

Download the binary for your platform from the latest release and place it somewhere on your $PATH.

Claude Code

Add to .claude/mcp.json in your project (or ~/.claude/mcp.json globally):

{
  "mcpServers": {
    "mtb": {
      "type": "stdio",
      "command": "mtb"
    }
  }
}

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "mtb": {
      "command": "mtb"
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "mtb": {
      "command": "mtb"
    }
  }
}

VS Code (Copilot)

Add to .vscode/mcp.json in your workspace:

{
  "servers": {
    "mtb": {
      "type": "stdio",
      "command": "mtb"
    }
  }
}

Cline

Open Cline settings in VS Code, click "MCP Servers", then "Configure MCP Servers" and add:

{
  "mcpServers": {
    "mtb": {
      "command": "mtb"
    }
  }
}

OpenAI Codex

Add to ~/.codex/config.toml (or .codex/config.toml in your project):

[mcp_servers.mtb]
command = "mtb"

Gemini CLI

Add to ~/.gemini/settings.json (or .gemini/settings.json in your project):

{
  "mcpServers": {
    "mtb": {
      "command": "mtb"
    }
  }
}

Build from source

go install github.com/dbravender/mtb@latest

Eating its own dog food

Running mtb on itself:

stats:

Estimated cost: $28,008 | People: 0.70 | Schedule: 3.5 months

deps: 644 packages detected

mtb ships with 644 transitive Go modules — nearly all from Syft, which brings in container runtimes, cloud SDKs, and archive format parsers to support 40+ package ecosystems. This is mtb practicing what it preaches: 6 source files, ~400 lines of production code, covering every ecosystem from npm to RPM by building on top of existing tools rather than reinventing them.

checklist: When run on itself, mtb scores well — CI enforces go vet, govulncheck, build, and tests on every push; releases are fully automated via tag-triggered cross-compilation; and documentation covers every tool and 7 editor integrations. Monitoring and on-call don't apply to a local CLI tool.

License

MIT