Bootify

Create a new Bootify project and return its project ID, URL, current setup and plan information. This changes server state and should only be called when the user wants a new project. Basic settings, developer preferences and database settings can be supplied during creation; omitted settings retain their defaults. All subsequent changes made through MCP are reflected live for the user at the returned project URL. Always show that URL to the user immediately after creating the project so they can follow the changes in their browser.

Return the current basic configuration and plan information of an existing Bootify project. Entity, relation, index and other object lists are returned only when explicitly selected through details. Successful calls record MCP usage and activity for this project.

Link an existing Bootify project to the bearer-authenticated user. Accepts either the project URL or its 12-character project ID and updates the project's plan.

Copy a project owned by the bearer-authenticated user. Projects with an active one-time upgrade cannot be copied.

Close a project owned by the bearer-authenticated user.

Update one or more basic settings of an existing Bootify project. Background information: https://bootify.io/docs/general-tab.html

Update one or more developer preferences of an existing Bootify project. Background information: https://bootify.io/docs/general-tab.html

Available with Bootify Professional. Update one or more advanced project options. MODULITH generates package-based application modules, while MULTI_MODULE generates physical Gradle or Maven modules. Select either before defining an application-module graph. Background information: https://bootify.io/docs/modules-tab.html

Include utilities for custom code even when the project does not require them. Required utilities cannot be disabled. They remain included when no longer required, until explicitly disabled. Omitted options retain their values. Inspect utilities in getProject for the current inclusion state.

Available with Bootify Professional. Enable or disable mail support and configure the generated application's SMTP connection.

Update one or more frontend settings of an existing Bootify project. Background information: https://bootify.io/docs/frontend-settings.html

Update the database and schema management settings of an existing Bootify project. Background information: https://bootify.io/docs/general-tab.html

Update one or more database naming settings of an existing Bootify project. Background information: https://bootify.io/docs/general-tab.html

Enable or disable generated date fields and configure their names. Background information: https://bootify.io/docs/general-tab.html

List dependencies that can be added to the generated Maven or Gradle build. These dependencies are managed by the project's Spring Boot version and therefore do not require a dependency version. Use the optional query to narrow the result. Successful calls record MCP usage and activity for this project.

Add an extra application dependency to the generated Maven or Gradle build. Bootify already adds dependencies required by selected project features. Call listAvailableDependencies to find supported coordinates, then pass the returned groupId:artifactId. Spring Boot supplies the compatible dependency version.

Remove a dependency from the generated Maven or Gradle build using groupId:artifactId. A version may be supplied but is not used for matching.

Available with Bootify Professional. Add a custom application module. References name the modules this module depends on. The same graph defines package boundaries for MODULITH and physical build modules for MULTI_MODULE; select either with updateAdvancedOptions first. The implicit base module is the lowest-level shared module and is integrated directly or transitively by every other module. A custom module with no references depends on base. The implicit web module is the highest-level application wrapper and automatically depends on every custom root module; in MULTI_MODULE it assembles the executable application. Neither implicit module can be edited. Dependencies must be acyclic and should point from a feature toward the lower-level modules it uses. Background information: https://bootify.io/docs/modules-tab.html

Available with Bootify Professional. Update or rename a custom application module identified by its current name. When provided, references replace all current direct dependencies. The same graph defines package boundaries for MODULITH and physical build modules for MULTI_MODULE; select either with updateAdvancedOptions first. The implicit base module is the lowest-level shared module and is integrated directly or transitively by every other module. A custom module with no references depends on base. The implicit web module is the highest-level application wrapper and automatically depends on every custom root module; in MULTI_MODULE it assembles the executable application. Neither implicit module can be edited. Dependencies must be acyclic and should point from a feature toward the lower-level modules it uses. Background information: https://bootify.io/docs/modules-tab.html

Delete a custom application module by name. The implicit base and web modules cannot be deleted. Bootify applies its consistency rules to references and assigned project elements. Available with Bootify Professional.

Add an enum to an existing Bootify project, identified by name.

Update or rename an enum identified by its current name. Provide newName, values, appModule, featurePackage, or several.

Delete an enum identified by name. Referencing fields are changed to String by Bootify's consistency rules.

Add a custom data object by name. Entity-generated DTOs are returned by getProject with generated=true and must be changed through their entity fields or REST/frontend options. Background information: https://bootify.io/spring-data/hibernate-json-type.html

Update or rename a custom data object by name. Entity-generated DTOs are returned by getProject with generated=true and must be changed through their entity fields or REST/frontend options. Background information: https://bootify.io/spring-data/hibernate-json-type.html

Delete a custom data object by name. Entity-generated DTOs are returned by getProject with generated=true and must be changed through their entity fields or REST/frontend options. Background information: https://bootify.io/spring-data/hibernate-json-type.html

Add an entity to an existing Bootify project. Entity, field, module, inheritance and custom field-type references use names.

Update or rename an entity identified by its current name. Only provided properties are changed; a provided fields array replaces all fields.

Delete an entity identified by name. Bootify applies its consistency rules to dependent project data.

Parse SQL DDL and reconcile its tables, fields and relations with an existing Bootify project. Matching entities are updated and new entities are added.

Available with Bootify Professional. Snapshot the current database schema so subsequent schema changes generate a new Flyway, Liquibase or Mongock changelog. Available only when getProject BREAKPOINTS reports AVAILABLE. Generated changelogs are blueprints and must be adapted to production data. Use this tool only after the user has explicitly confirmed adding a breakpoint.

Available with Bootify Professional. Permanently remove one breakpoint. This changes generated changelogs and cannot be undone. Copy its epoch-second ID from getProject BREAKPOINTS. Use this tool only after the user has explicitly confirmed removing the breakpoint.

Add a relation whose type describes the cardinality from fromEntity to toEntity. For MANY_TO_ONE, ONE_TO_ONE and MANY_TO_MANY the owning field is fromEntity.fromField; for ONE_TO_MANY it is toEntity.toField. The response includes that canonical owning-side value as identifier. Bidirectional relations require both fields. Background information: https://bootify.io/docs/jpa-relationship-types-with-examples.html. fromEntity and toEntity must already exist. The owning entity's application module must depend on the target entity's module.

Update a relation whose type describes the cardinality from fromEntity to toEntity. For MANY_TO_ONE, ONE_TO_ONE and MANY_TO_MANY the owning field is fromEntity.fromField; for ONE_TO_MANY it is toEntity.toField. The response includes that canonical owning-side value as identifier. Bidirectional relations require both fields. Background information: https://bootify.io/docs/jpa-relationship-types-with-examples.html. Identify the existing relation with its current identifier returned by addRelation, updateRelation or getProject; do not reconstruct internal IDs. Only provided relation properties are changed. If an update changes the owning entity or field, use the newly returned identifier for subsequent calls.

Delete a relation using the current identifier returned by addRelation, updateRelation or getProject with RELATIONS details. The identifier is the owning entity and owning field joined with a dot; copy it verbatim because ONE_TO_MANY ownership is on the to side.

Add a normal or unique index over ordered entity fields or owning-side relations. Many-to-many relations are excluded. The response returns its name selector as Entity.field1-field2.

Update an index by its current Entity.field1-field2 identifier. Only provided properties are changed; the response contains its updated identifier.

Delete an index by its current name.

Available with Bootify Professional. Add a custom REST controller by name. Entity-generated controllers are returned by the matching getProject details option with generated=true and must be changed through their entity options.

Available with Bootify Professional. Update or rename a custom REST controller by name. Entity-generated controllers are returned by the matching getProject details option with generated=true and must be changed through their entity options.

Available with Bootify Professional. Delete a custom REST controller by name. Entity-generated controllers are returned by the matching getProject details option with generated=true and must be changed through their entity options.

Available with Bootify Professional. Add a custom frontend controller by name. Entity-generated controllers are returned by the matching getProject details option with generated=true and must be changed through their entity options.

Available with Bootify Professional. Update or rename a custom frontend controller by name. Entity-generated controllers are returned by the matching getProject details option with generated=true and must be changed through their entity options.

Available with Bootify Professional. Delete a custom frontend controller by name. Entity-generated controllers are returned by the matching getProject details option with generated=true and must be changed through their entity options.

Return the canonical METHOD /path values that may be assigned to security roles. Pass securityConfigName while editing so that its current paths remain available. Frontend paths can only be protected by BASIC_AUTH, FORM_SESSION or KEYCLOAK_CLIENT. Successful calls record MCP usage and activity for this project.

Create a config with safe defaults. Configure roles, login and an optional user source through their dedicated tools.

Change only the identity, type, module or authentication mode. Changing type resets type-specific settings to defaults.

Configure only login, JWT, Keycloak and session behavior. Provide just the fields that should change.

Configure the user entity and its credential, OAuth mapping, password reset and token fields. Provide just the fields that should change.

Replace the role setup. Call listSecurityPaths first and use its exact METHOD /path values.

Delete a security configuration by name.

Available with Bootify Professional. Generate and return the OpenAPI document for the current project configuration. Use it to inspect resolved paths, parameters, request and response schemas, status codes and security schemes before exporting the project. Successful calls record MCP usage and activity for this project.

Return every file path that would be present in the ZIP export of an existing Bootify project, without generating or returning file contents. Listing fails when the project plan has expired. Successful calls record MCP usage and activity for this project.

Return one generated project file. The path may exactly match a value returned by listProjectFiles, with or without the project root directory, such as pom.xml. Text is returned as UTF-8 and binary content as Base64. Successful calls record MCP usage and activity for this project. Generated files can include private signing keys for RSA JWT configurations; treat them as sensitive.

Return a ZIP download URL for an existing Bootify project. This tool should be called after all project details and the schema have been configured with the user and the current setup has been presented. Ask for approval before exporting unless the user already explicitly requested the export in the current context. The client can download and extract it when the environment supports it. Export fails when the project plan has expired. Successful calls record MCP usage and activity for this project. Generated files can include private signing keys for RSA JWT configurations; treat them as sensitive.

Available with Bootify Professional. Return the saved repository URL, target branch and defaultCommitMessage derived from current changes using the builder's commit message generator. This does not contact the remote or preview a Git diff. Credentials are never returned. If unconfigured, open configurationUrl to configure Git in the builder. Successful calls record MCP usage and activity for this project.

Available with Bootify Professional. Generate, commit and push to the saved repository and target branch. Replaces the target branch's file contents with the generated project, including deleting other files. Use only when the user has authorized the Git export. Inspect getGitExportStatus first. The optional message overrides defaultCommitMessage; when omitted it is calculated at export time. No commit is created when generated files have not changed; commitSha is then null. Requires saved Git credentials and active export access. Successful calls record MCP usage and activity.