The regeneration contract

Run it as often as you like. What updates, what never moves, and why.

Codegen tools earn trust one way: by what they do on the second run. This one is built to be re-run every time your API changes.

The rules

SituationWhat happens
An endpoint is addedA new file appears, ready to use
The spec changedOnly the part generated from the spec updates
Nothing changedNothing gets rewritten; your git history stays quiet
You edited the generated partYour version wins; the update waits in a separate .new file

How it works

Each tool file has two regions, split by a marker comment:

src/webmcp/delete-pet.webmcp.ts
// ─── webmcp-codegen: generated. Do not edit this region. ───

//   name, description, input schema, input type, hints, register()
//   ... everything derived from the API contract

// ─── webmcp-codegen: end generated. Your code below survives regeneration. ───

export async function executeDeletePet(input: DeletePetInput) {
  // This tool starts disabled: it changes things. ...
  return toolDisabled("delete-pet.webmcp.ts");

  // const data = await callApi(`/pets/${input.id}`, { method: "DELETE" });
  // return toolResult(data);
}

Everything above the end-marker is regenerated freely: it tracks your spec exactly. Everything below it was written once and is never touched again. The scaffold below the marker is working code (reads) or working code one uncomment away (mutations), so "owning" the region usually means editing behavior, not writing plumbing.

Two support files are fully regenerated on every run and say so in their header: runtime.webmcp.ts (the shared helpers: callApi, toolResult, toolDisabled, getModelContext, requestUserConfirmation) and index.ts (the registerAllTools() barrel).

What never gets touched

  • Your execute() implementations and anything else below the marker.
  • Your overrides in .webmcp-codegen.json (descriptions, enabled flags). They apply after every regeneration, so dashboard edits survive.

Conflicts

If you edit above the marker on purpose (you own the files; maybe you had a reason), the next run does not fight you: it leaves your file alone and writes its version to <name>.webmcp.ts.new with a header explaining what happened. You merge by hand and delete the .new file.

No dependency on the tool

Generated files import only from each other. Nothing at runtime imports webmcp-codegen. Uninstall the package, delete the config, and everything you generated keeps working. That is the point of generating code instead of hiding it in a library.