Skip to main content
Glama

Update developer preferences

updateDeveloperPreferences
Destructive

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "updateDeveloperPreferences"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectIdYesThe project ID returned by startProject
deploymentNo
javaVersionNo
openApiEnabledNoGenerate OpenAPI documentation and Swagger UI
packageStructureNoPackage layout: TECHNICAL groups classes by technical type in packages such as domain, repos, service and rest; DOMAIN_DRIVEN groups all classes related to an entity in a package named after that entity; MIXED creates an entity package with technical subpackages.
applicationFormatNoFormat of the generated Spring application configuration
dockerComposeEnabledNoGenerate Docker Compose support for local development
includeAgentInstructionsNoGenerate AGENTS.md with coding agent instructions

Output Schema

NameRequiredDescriptionDefault
changesYesOnly settings whose values actually changed, including automatic effects, using final stored values in MCP format. Nested objects contain changed properties only. Empty when no settings changed; values that are no longer exposed are omitted.
projectIdYesThe project ID returned by startProject
affectedAreasYesObject lists changed directly or by automatic effects. Lists are not returned; use getProject with these details when needed. Empty for no list changes.
userProjectChangedNoPresent only once when the project appears to have been changed by the user since the preceding MCP call within the last two hours

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / affectedAreas / items / enum
      Previous value: -[
      -  "APP_MODULES",
      -  "ENUMS",
      -  "DATA_OBJECTS",
      -  "ENTITIES",
      -  "RELATIONS",
      -  "INDEXES",
      -  "REST_CONTROLLERS",
      -  "FRONTEND_CONTROLLERS",
      -  "SECURITY_CONFIGS"
      -]New value: +[
      +  "APP_MODULES",
      +  "ENUMS",
      +  "DATA_OBJECTS",
      +  "ENTITIES",
      +  "RELATIONS",
      +  "INDEXES",
      +  "BREAKPOINTS",
      +  "REST_CONTROLLERS",
      +  "FRONTEND_CONTROLLERS",
      +  "SECURITY_CONFIGS"
      +]
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds only that the update is partial ('one or more') but does not explain what gets destroyed, why the operation is not idempotent, or how it affects generated project files.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and resource, and the second sentence is a documentation link rather than filler. No redundant or wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a destructive mutation with 8 parameters, an output schema, and rich annotations, yet the description does not explain how the partial update interacts with existing preferences or what the destructive effect actually is. It is adequate given the annotations and output schema, but leaves meaningful context unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 8 parameters and 75% schema description coverage, the schema provides meaningful descriptions for most fields, and the enum-constrained parameters (deployment, javaVersion, packageStructure, applicationFormat) are largely self-explanatory. The description adds no further meaning, but the schema carries the majority of the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Update) and resource (developer preferences) scoped to an existing Bootify project, so the purpose is clear. However, it does not differentiate the tool from sibling update tools such as updateSettings or updateAdvancedOptions, leaving the agent to infer the boundary from parameters alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage ('Update one or more developer preferences of an existing Bootify project') but provides no explicit when-to-use guidance, no exclusions, and no alternatives among the many sibling update tools. It is minimum viable with clear gaps.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources