Get your API key from the Buildd dashboard under Accounts.

Two things narrow the list further:

• A trigger token sees four tools — check_path_claim and send_worker_message are not registered for it.
• In a workspace whose dataClass is sensitive, the three knowledge tools (recall, learn, buildd_memory) are not registered at all.

If you are writing a --allowedTools allowlist for CI, list the tools you actually need by name — mcp__buildd__buildd, mcp__buildd__recall, mcp__buildd__learn — because a tool you omit cannot be called.

A single buildd API key covers all of them. Memory is built into buildd — there is no separate memory service, no separate signup, and no second key. The retired memory.buildd.dev service and its mem_* keys are gone; see Memory.

list_schedules is available at every token level, and it is the recommended probe for telling a privilege failure from an expired key: if list_schedules works but an admin action returns forbidden, your token is authentic and simply lacks admin level.

update_task forwards only title, description, priority, project, status, backend and maxLoops. Unlike create_task, it does not reject unknown parameters — anything else you pass is discarded silently and the call still reports success. In particular dependsOn and requiresReview do nothing here; see Task Dependencies and Autonomous Workflow.

update_progress with plan does not submit a plan for review. It appends a type: "plan" entry to the worker's milestone timeline and nothing else — no gate, no approval state, no child tasks. It is a progress annotation.

A reviewable plan is returned as validated structured output at complete_task. When a task's mode is planning, the runner asks the model for output constrained to the planning schema — plan (an array of steps with ref, title, description, and optional dependsOn), summary, and missionComplete — and reports it as structuredOutput. buildd action=approve_plan then reads task.result.structuredOutput.plan and materialises the child tasks. If the plan came back as prose instead, approve_plan fails with No plan found in task result.

buildd action=complete_task params={
  workerId: "...",
  summary: "Decomposed into 3 steps",
  structuredOutput: {
    plan: [
      { ref: "s1", title: "Add middleware", description: "..." },
      { ref: "s2", title: "Update routes", description: "...", dependsOn: ["s1"] }
    ],
    summary: "Auth refactor in two steps",
    missionComplete: false
  }
}

register_skill and update_skill still accept mcpServers and requiredEnvVars, and still store them — but they are no longer used to build a role's MCP configuration. MCP servers are injected at claim time from connectors; use connectorRefs to opt a role into them. The role bundle written to storage carries mcpConfig: {} and envMapping: {} by design.

They are not entirely inert: the claim path still reads mcpServers['codebase-memory'] === false as an opt-out flag for that one server. Anything else you put there is stored and ignored.

manage_missions create (and update) accept a branchStrategy of mission-branch or direct, overriding the workspace default for that one mission. Under mission-branch, buildd creates the mission's shared branch automatically — there's nothing to set up by hand. See Mission Branches for how each strategy gets a mission's work into your trunk branch.

If the PR cannot be read to evaluate the policy, the merge is refused rather than attempted. A merge with no policy evaluation is the thing this gate exists to prevent, so an unreadable PR fails closed.

recall's input schema also advertises type and files, but the handler reads neither. Passing them changes nothing and raises no error — you get unfiltered results that look filtered. Narrow with query and scope instead.

The legacy buildd_memory action=search does honour type and files, so it remains the only way to get a real type or file filter over memory.

scope is not the same field on both tools. On recall it picks the corpus to search; on learn it is the project/monorepo name. Don't copy one into the other.

buildd_memory action=update writes type without validating it, unlike save and learn, which both enforce the five allowed types. A typo'd type is stored verbatim and the memory then disappears from every type-filtered query.