Summary
The FlutterFlow AI SDK (and by extension the MCP server it exposes) has no DSL surface for instantiating custom code on a page. This applies to both project-local custom code and library-sourced custom code, and it currently blocks AI agents from completing common end-to-end tasks like wiring up a marketplace library.
What works today
app.libraryComponent(name, params: {...}) — library components can be instantiated on pages.app.libraryPage(...) — library pages can be referenced for navigation.app.customAction(...), app.customWidget(...), addCustomAction(...), addCustomWidget(...) — custom code can be declared/added to a project.
What's missing
There is no DSL way to do any of the following:
-
Place a custom widget on a page — neither project-local nor library-sourced. The references/custom_code_pub_package_dsl.dart reference suggests a CustomWidget('Name', params: ...) invocation form, but the CustomWidget class does not exist anywhere in the SDK source. So even widgets a developer adds via app.customWidget(...) cannot be inserted into a body: tree.
-
Invoke a custom action from an action chain — neither project-local nor library-sourced. There is no CallCustomAction DslAction class. The lower-level FFAction.callCustomAction(identifier:) exists in lib/src/ui/actions.dart, but it requires raw FFIdentifier plumbing via app.raw(...) and is not surfaced in the DSL action vocabulary alongside Navigate, SetState, ApiCall, ExecuteActionBlock, etc.
-
Wire actions to app-level "Final Actions" (main.dart) — the schema supports it (FFCustomFile_Action_Type.FINAL_ACTION on project.customCode.customFiles.files), but there is no SDK helper. Required for any library that needs startup hooks (analytics, ads, push notifications, ATT prompts, etc.).
Why this matters
These three gaps together mean an AI agent driving the SDK can install a marketplace library successfully (the dependency adds fine) but cannot complete the wiring that makes the library actually do anything. Concretely, for the AdMob Library you can:
- ✅ Add the library dependency
- ✅ See its custom actions and custom widgets in
flutterflow ai inspect
- ❌ Place its banner widget on a page
- ❌ Call its init/load actions on app startup
- ❌ Wire its startup actions into main.dart Final Actions
The same pattern blocks any library whose surface is custom widgets and/or custom actions (which is, presumebly, most of them ).
The result is that an agent has to stop mid-task and ask the user to switch to the FlutterFlow editor UI to complete every library setup, which defeats the point of the agent surface.
Proposed additions
Surface area that would close the gap:
CustomWidget('Name', params: {...}) DslWidget — for project-local widgets.LibraryCustomWidget(libraryProjectId, 'Name', params: {...}) DslWidget — for library-sourced widgets. Or a unified handle (app.libraryCustomWidget(...) / app.existingCustomWidget(...)) that returns an instantiable handle.CallCustomAction(target, params: {...}) DslAction — symmetrical to ExecuteActionBlock. Should accept project-local and library-scoped targets.app.editAppFinalActions([...]) / equivalent helper for FFCustomFile_Action_Type.FINAL_ACTION and INITIAL_ACTION on main.dart.- Update
references/custom_code_pub_package_dsl.dart so its CustomWidget(...) example reflects the actual SDK once shipped.
Environment
- Encountered via the FlutterFlow AI SDK / MCP integration (vendored under
.flutterflow/sdk/flutterflow_ai/).
- Verified against current SDK source: no
CustomWidget DslWidget class, no CallCustomAction DslAction class, no editAppFinalActions helper.
Summary
The FlutterFlow AI SDK (and by extension the MCP server it exposes) has no DSL surface for instantiating custom code on a page. This applies to both project-local custom code and library-sourced custom code, and it currently blocks AI agents from completing common end-to-end tasks like wiring up a marketplace library.
What works today
app.libraryComponent(name, params: {...})— library components can be instantiated on pages.app.libraryPage(...)— library pages can be referenced for navigation.app.customAction(...),app.customWidget(...),addCustomAction(...),addCustomWidget(...)— custom code can be declared/added to a project.What's missing
There is no DSL way to do any of the following:
Place a custom widget on a page — neither project-local nor library-sourced. The
references/custom_code_pub_package_dsl.dartreference suggests aCustomWidget('Name', params: ...)invocation form, but theCustomWidgetclass does not exist anywhere in the SDK source. So even widgets a developer adds viaapp.customWidget(...)cannot be inserted into abody:tree.Invoke a custom action from an action chain — neither project-local nor library-sourced. There is no
CallCustomActionDslActionclass. The lower-levelFFAction.callCustomAction(identifier:)exists inlib/src/ui/actions.dart, but it requires rawFFIdentifierplumbing viaapp.raw(...)and is not surfaced in the DSL action vocabulary alongsideNavigate,SetState,ApiCall,ExecuteActionBlock, etc.Wire actions to app-level "Final Actions" (main.dart) — the schema supports it (
FFCustomFile_Action_Type.FINAL_ACTIONonproject.customCode.customFiles.files), but there is no SDK helper. Required for any library that needs startup hooks (analytics, ads, push notifications, ATT prompts, etc.).Why this matters
These three gaps together mean an AI agent driving the SDK can install a marketplace library successfully (the dependency adds fine) but cannot complete the wiring that makes the library actually do anything. Concretely, for the AdMob Library you can:
flutterflow ai inspectThe same pattern blocks any library whose surface is custom widgets and/or custom actions (which is, presumebly, most of them ).
The result is that an agent has to stop mid-task and ask the user to switch to the FlutterFlow editor UI to complete every library setup, which defeats the point of the agent surface.
Proposed additions
Surface area that would close the gap:
CustomWidget('Name', params: {...})DslWidget— for project-local widgets.LibraryCustomWidget(libraryProjectId, 'Name', params: {...})DslWidget— for library-sourced widgets. Or a unified handle (app.libraryCustomWidget(...)/app.existingCustomWidget(...)) that returns an instantiable handle.CallCustomAction(target, params: {...})DslAction— symmetrical toExecuteActionBlock. Should accept project-local and library-scoped targets.app.editAppFinalActions([...])/ equivalent helper forFFCustomFile_Action_Type.FINAL_ACTIONandINITIAL_ACTIONon main.dart.references/custom_code_pub_package_dsl.dartso itsCustomWidget(...)example reflects the actual SDK once shipped.Environment
.flutterflow/sdk/flutterflow_ai/).CustomWidgetDslWidgetclass, noCallCustomActionDslActionclass, noeditAppFinalActionshelper.