Skip to main content
Glama

build

Destructive

Analyzes project code, decomposes a goal into tasks, edits code, and verifies each change via build/test

Instructions

Autonomously plan AND execute a goal in a project, from scratch.

Use when: you have a goal but no existing task plan — ``build`` analyzes the
project, decomposes ``goal`` into tasks, edits the code, and verifies each
change through build/test/lint/typecheck gates, reverting anything that
regresses. Do NOT use when: a task plan already exists and you just want to
execute it (use ``run``), or the working tree is dirty (commit/stash first).
Related: ``run`` (execute an existing plan), ``status`` (inspect tasks).
Pass ``reference_dir`` to port from an existing implementation: its
module/symbol map is extracted read-only and guides the plan.
Pass ``spec_text`` when you have already written the implementation spec
(e.g. in a Claude conversation) — misterdev skips its own planning phase
and executes your spec directly, making it Claude's execution backend.

DESTRUCTIVE side effects: edits files and makes git commits, and calls an
external LLM provider (open-world, non-idempotent). It refuses to run on a
dirty working tree. ``dry_run=True`` previews without changing anything;
``budget`` caps spend; ``max_tasks`` caps scope.

Returns a compact text report: what was done, per-gate results, and cost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYesPlain-English description of what to build, or a mode word: 'debug' (fix what's broken), 'complete' (finish unfinished work), or 'review'. Example: 'add rate limiting to the public API'.
pathYesAbsolute path to the project directory to build (containing project.yaml). Its git working tree must be clean. Example: '/Users/me/code/my-api'.
budgetNoMaximum US dollars to spend on this run. Must be > 0; the run halts when reached. Example: 5.0.
dry_runNoWhen true, plan and preview the tasks without editing any code or spending beyond planning. Example: true.
parallelNoWhen true, run independent tasks concurrently in isolated git worktrees. Example: false.
max_tasksNoCap how many tasks are planned/executed (bounds cost and scope). Must be >= 1; omit for no cap. Example: 5.
spec_textNoA complete implementation spec in markdown — supply this when you have already analysed the codebase and written the spec yourself (e.g. from a Claude conversation). misterdev will skip its own analysis and spec-generation phases and go straight to decompose → execute → verify using your spec. Omit to let misterdev analyse and generate the spec from ``goal``.
reference_dirNoAbsolute path to a reference implementation to port from (often in another language). Its module/symbol map is extracted READ-ONLY and given to the planner so the build reproduces the reference's design idiomatically. Omit when not porting. Example: '/Users/me/code/donor-impl'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changedv0.6.0
    • addedInput schema / properties / reference_dir
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Absolute path to a reference implementation to port from (often in another language). Its module/symbol map is extracted READ-ONLY and given to the planner so the build reproduces the reference's design idiomatically. Omit when not porting. Example: '/Users/me/code/donor-impl'.",
      +  "examples": [
      +    "/Users/me/code/donor-impl"
      +  ],
      +  "title": "Reference Dir"
      +}
    • addedInput schema / properties / spec_text
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "A complete implementation spec in markdown — supply this when you have already analysed the codebase and written the spec yourself (e.g. from a Claude conversation). misterdev will skip its own analysis and spec-generation phases and go straight to decompose → execute → verify using your spec. Omit to let misterdev analyse and generate the spec from ``goal``.",
      +  "title": "Spec Text"
      +}
  2. Changed15 schema fields changedv0.2.2
    • changedInput schema / properties / budget / description
      Previous value: -"Maximum dollars to spend on this run."New value: +"Maximum US dollars to spend on this run. Must be > 0; the run halts when reached. Example: 5.0."
    • addedInput schema / properties / budget / examples
      Added value: +[
      +  5,
      +  25
      +]
    • changedInput schema / properties / dry_run / description
      Previous value: -"Plan and preview tasks without editing any code."New value: +"When true, plan and preview the tasks without editing any code or spending beyond planning. Example: true."
    • addedInput schema / properties / dry_run / examples
      Added value: +[
      +  false,
      +  true
      +]
    • changedInput schema / properties / goal / description
      Previous value: -"Plain-English goal, or a mode word: 'debug', 'complete', or 'review'."New value: +"Plain-English description of what to build, or a mode word: 'debug' (fix what's broken), 'complete' (finish unfinished work), or 'review'. Example: 'add rate limiting to the public API'."
    • addedInput schema / properties / goal / examples
      Added value: +[
      +  "add rate limiting to the public API",
      +  "debug",
      +  "complete"
      +]
    • addedInput schema / properties / goal / minLength
      Added value: +1
    • changedInput schema / properties / max_tasks / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "minimum": 1,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / max_tasks / description
      Previous value: -"Cap how many tasks are planned/executed (bounds cost)."New value: +"Cap how many tasks are planned/executed (bounds cost and scope). Must be >= 1; omit for no cap. Example: 5."
    • addedInput schema / properties / max_tasks / examples
      Added value: +[
      +  5,
      +  10
      +]
    • changedInput schema / properties / parallel / description
      Previous value: -"Run independent tasks concurrently in isolated git worktrees."New value: +"When true, run independent tasks concurrently in isolated git worktrees. Example: false."
    • addedInput schema / properties / parallel / examples
      Added value: +[
      +  false,
      +  true
      +]
    • changedInput schema / properties / path / description
      Previous value: -"Path to the project to build (its directory)."New value: +"Absolute path to the project directory to build (containing project.yaml). Its git working tree must be clean. Example: '/Users/me/code/my-api'."
    • addedInput schema / properties / path / examples
      Added value: +[
      +  "/Users/me/code/my-api"
      +]
    • addedInput schema / properties / path / minLength
      Added value: +1
  3. First observedv0.2.1

TDQS

A5/5.0
Behavior5/5

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

Builds on annotations (destructiveHint=true, etc.) by detailing side effects: edits files, makes git commits, calls external LLM, refuses on dirty tree, dry_run preview, budget caps, max_tasks caps. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: front-loaded with core purpose, then usage guidelines, then behavioral notes, then return. Every sentence is informative with no redundancies.

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

Completeness5/5

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

For a high-complexity tool (8 params, external LLM calls, destructive), the description covers purpose, guidelines, behavior, parameters, and return format. Completely adequate without gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant meaning beyond schema: explains mode words for goal, skips planning with spec_text, porting with reference_dir, budget halting, etc. Each parameter is enriched.

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 'Autonomously plan AND execute a goal in a project, from scratch.' with specific verb and resource. It distinguishes from siblings like 'run' and 'status' by stating when not to use this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when:' and 'Do NOT use when:', naming alternatives (run, status) and conditions (dirty working tree). Also provides guidance for spec_text and reference_dir parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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/dcondrey/misterdev'

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