Builder MCP Change and Extension Workflow

Use Builder MCP to modify existing Buzzy apps, generate code widgets, add Buzzy Functions, and verify changes.

Use this example when an app already exists and you need to change it safely.

Builder MCP gives an AI coding agent access to the app definition, not just screenshots or vague prose. That means the agent can inspect the current brief, flows, data model, blueprint, theme, screens, functions, constants, and code widgets before proposing or applying a change.

Good Change Requests

Builder MCP is useful for:

• adding a new dashboard or workflow screen

• changing the data model and then updating dependent screens

• creating or updating a code widget

• creating a Buzzy Function for an external API

• adding constants and secrets for server-side integrations

• wiring a function to a screen action

• fixing broken bindings or stale navigation

• adding Release Tests for important flows

• reviewing security before exposing data through REST API or Custom MCP

Change Loop

1. Pull or inspect the current app definition.

2. Identify the accepted source of truth: brief, flows, data model, blueprint, theme, and screens.

3. Decide whether the requested change affects upstream artifacts.

4. Update the smallest correct artifact first.

5. Push the artifact.

6. Re-read and verify the saved result.

7. Update dependent screens, functions, widgets, or navigation.

8. Test with preview, screenshots, Release Tests, or browser verification.

9. Run Security Review if the change touches sensitive data, roles, APIs, MCP, functions, or external systems.

Example: Add a Code Widget

Ask Builder MCP to inspect the target screen, accepted data model, and current layout before creating the widget.

Example instruction:

Add a compact service-availability calendar widget to the Carer Profile screen.

Use the accepted data model fields for carer availability, do not invent field IDs, and keep the widget scoped to the selected carer row. The widget should show available time windows, unavailable days, and a request-care action that passes the selected slot back to the screen.

The agent should update the screen placement first, then the code widget internals, then verify row context, field bindings, shared-state keys, and action output.

Example: Add a Buzzy Function

Use Buzzy Functions for server-side behavior such as external APIs, webhooks, AI provider calls, and privileged logic.

Example instruction:

Create a Buzzy Function that checks service-area eligibility for a booking request.

Inputs: client suburb, requested service type, requested date/time, and selected carer ID.
Use constants for any external API keys or base URLs.
Return a structured eligibility result with allowed, reason, and suggestedAlternatives.
Wire the function to the booking request screen and show a user-friendly message.

The agent should declare constants, write the function, align sample payloads to the caller, wire the screen action, and test allowed and denied cases.

Verification Checklist

• The brief still describes the app accurately.

• The data model contains the real fields used by screens, functions, and widgets.

• Screen bindings use persisted table and field IDs.

• Navigation targets exist.

• Function inputs match the screen action payload.

• Constants do not expose secrets.

• Code widgets do not contain stale source-app IDs or labels.

• Release Tests cover the changed workflow.

• Security Review findings have been read and acted on where relevant.

Related Pages

• Buzzy Builder MCP

• Code Widget Examples

• Buzzy Functions & Constants

• Release Tests

• Security Review