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
| Situation | What happens |
|---|---|
| An endpoint is added | A new file appears, ready to use |
| The spec changed | Only the part generated from the spec updates |
| Nothing changed | Nothing gets rewritten; your git history stays quiet |
| You edited the generated part | Your version wins; the update waits in a separate .new file |
How it works
Each tool file has two regions, split by a marker comment:
// ─── 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.