Docs · Integrations

Builderius

Read the Builderius template and version graph, components, releases and settings, and author templates by committing configs through its own versioning.

Builderius is one of the builders NIBWP turns into a set of typed, agent-callable tools. It is unusual among builders in that it versions everything the way source control does, and the integration works with that rather than around it.

Because Builderius keeps a template graph with versions, branches and releases, an agent can author a change as a commit rather than as an overwrite. That means the thing an agent builds is reviewable and revertable by design, which is rarely true of builder output.

TL;DR

Active plugin in, typed tools out. Read the template and version graph, components, fragments, releases and global settings, and author new versions by committing configs through Builderius’s own git-like versioning.

A builder with history

Connecting Builderius to your agents changes what is possible with it:

  • Versioned authoring — Changes land as commits on a branch, not as an irreversible overwrite.
  • The whole graph — Templates, versions, components, fragments and releases are all readable.
  • Config in, config out — Export and import configuration, so a site can be described as data.
  • Component reuse — Read components and build new templates from what already exists.
  • Form submissions — Read submissions alongside the templates that produced them.
  • Reviewable output — Because it commits, an agent change can be inspected before release.

What it exposes

Twenty-one abilities go live automatically the moment Builderius is detected. The read side covers the whole graph:

AbilityTypeWhat it does
nibwp/builderius-list-templatesreadList templates in the project.
nibwp/builderius-get-templatereadRead a single template and its current version.
nibwp/builderius-list-versionsreadList versions for a template, the history behind it.
nibwp/builderius-list-componentsreadList reusable components.
nibwp/builderius-list-releasesreadList releases, the published points in the graph.
nibwp/builderius-list-fragmentsreadList fragments.
nibwp/builderius-list-global-settingsreadRead the global settings.
nibwp/builderius-list-form-submissionsreadRead form submissions.
nibwp/builderius-build-configreadAssemble a config object for a change before committing it.
nibwp/builderius-create-templatewriteCreate a template by committing a config.
nibwp/builderius-update-templatewriteCommit a new version of an existing template.
nibwp/builderius-create-componentwriteCreate a reusable component.
nibwp/builderius-create-branchwriteBranch the graph so work can proceed without touching the released version.
nibwp/builderius-import-configwriteImport a configuration into the project.
nibwp/builderius-deletemanageRemove an object from the graph.

The list above is the shape of it rather than the whole set: list-starters, list-modules, get-component, create-fragment, update-global-settings and export-config round it out to twenty-one.

From hours to one prompt

Ask for the outcome and let the agent choose the calls:

agenttext
Branch off the current release and add a pricing template built from existing components

nibwp/builderius-create-branch (run)
nibwp/builderius-list-components (run)
nibwp/builderius-build-config (run)
nibwp/builderius-create-template (run)
✓ committed · 4 tools · 3.8s

The work lands as a commit on a branch, so you can look at it before it becomes a release.

What you can build

A few of the things teams do with the Builderius integration:

Template authoring

Build a new template from existing components and commit it for review.

Graph audits

Report which templates have drifted from their release.

Config portability

Export a configuration and import it into another project.

Safe experiments

Branch, try something, and discard it without touching what is live.

How it stays safe

  • Versioned by nature — Changes are commits, so there is always a previous version to return to.
  • Branch before you build — An agent can work on a branch and leave the released version untouched.
  • Every change logged — Each call is recorded with the account, the tool and the result.
  • Delete is separate — Removing anything from the graph needs the manage scope, not write.

Getting started

  • Activate Builderius — The integration appears in NIBWP the moment the plugin is detected.
  • Connect a client — Point any MCP client at your NIBWP endpoint and approve the scopes you want.
  • Walk the graph — Start with list-templates and list-versions to see how the project is shaped.
Branch firstBecause Builderius versions everything, the safe pattern is to branch before an agent authors anything. A commit on a branch costs nothing and can simply be abandoned.

FAQ

Does it overwrite my templates?
No. Authoring goes through Builderius’s own versioning, so a change is a new version rather than a replacement.
Can I review before it goes live?
Yes. Commit on a branch, read it, and release it only when you are happy.
What is build-config for?
It assembles the configuration object for a change so the commit is well formed before it is made.
Can it delete things?
Only with the manage scope, which is separate from write and unticked by default.

Connect Builderius

Activate the plugin, connect an MCP client, and let agents commit work for review.

Browse integrations

Connect your first agent.

Follow the quickstart, or book a demo and we'll walk you through it.