Skip to main content
Glama

Update project settings

update_settings
DestructiveIdempotent

Change the settings of one project. Send project_id and only the fields to change; a field left out keeps its current value. Returns ok and a short message.

Build settings (ref, framework, runtime_version, build_cmd, dependencies_cmd, sub_path, output_directory) apply to the next build. port and health_check_path restart the running app. storage_mount_path applies on the next deploy. display_name renames the project.

Visibility: default_public sets whether commits created later are public or owner-only; existing commits keep their visibility. auto_promote_on_main_build sets whether a successful build of the tracked ref becomes the production version automatically.

Sign-in gate: google_login ('on' or 'off') puts the platform's Google sign-in in front of the app's canonical host, or removes it, and applies to the live host immediately. google_login_mode and google_login_allowed_emails set who may pass and also apply immediately; removing an address ends that person's access on their next request.

Environment variables are not changed by this tool; set_env_vars does that. Requires a read-write token.

Input Schema

NameRequiredDescriptionDefault
refNotracked branch/tag (the ref auto-promote follows)
portNocontainer port; change rolls the deployed pods
sub_pathNobuild sub-directory; applies to the next build
build_cmdNobuild command; applies to the next build
frameworkNoframework preset; applies to the next build
project_idYesthe project id (from list_projects)
display_nameNohuman-friendly project name
google_loginNo'on' gates the app's canonical host behind Google sign-in (the platform runs the OAuth flow; the app receives X-Kad-User/X-Kad-Email/X-Kad-Project headers), 'off' removes the gate. Applies to the live canonical host immediately.
default_publicNowhether new commits default to public
runtime_versionNoruntime version; applies to the next build
dependencies_cmdNoinstall command; applies to the next build
output_directoryNostatic output directory; applies to the next build
google_login_modeNowho gets through the Google gate: 'anyone' (any verified Google account) or 'restricted' (only google_login_allowed_emails). Takes effect immediately, no redeploy. Switching to 'restricted' with no list seeds the owner's own address so they don't lock themselves out.
health_check_pathNoHTTP health-check path; change rolls the deployed pods
storage_mount_pathNoabsolute path where the app's persistent disk mounts, e.g. /data; empty removes it. Setting it on an app that has no disk (a new app has none) creates the disk. Applies on the next deploy
auto_promote_on_main_buildNoauto-promote successful builds of the tracked ref to canonical
google_login_allowed_emailsNothe email addresses allowed in 'restricted' mode; replaces the whole list. Removing an address revokes that person on their next request.

Output Schema

NameRequiredDescriptionDefault
okYes
statusNopresent, and always "pending_approval", only when this call was parked instead of run immediately because the project's (or kad-back's own) plan-mode setting requires a human to approve it first
messageYes
plan_idNopoll get_plan_status with this id for the eventual outcome
approve_atNothe kad.dev dashboard URL a human approves or rejects this plan from
expires_in_sNothe plan can no longer be approved after this many seconds

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, the description details when changes take effect: build settings apply to the next build, port and health_check_path restart the running app, storage_mount_path applies on the next deploy, and sign-in gate changes apply immediately. It also clarifies that existing commits keep their visibility and that removing an allowed email address ends access on the next request.

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?

Despite being a long description for a 17-parameter mutation tool, it is front-loaded with the core partial-update contract and organized into clear paragraphs for build settings, visibility, sign-in gate, and environment-variable exclusions. The sentences carry operational information rather than filler.

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

Completeness5/5

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

With annotations present, an output schema available, and 100% schema description coverage, the description still adds the important behavioral context: partial-update semantics, field-specific timing, visibility effects, sign-in gate behavior, env-var exclusion, and authentication requirements. Nothing material appears missing for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-field meaning by grouping parameters and saying omitted fields keep their current value. It also reinforces effect timing for groups such as build settings versus live sign-in gate settings, though much of the per-parameter detail already exists in the schema.

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

Purpose5/5

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

The first sentence states a specific verb and resource: 'Change the settings of one project.' It also distinguishes the tool from set_env_vars by explicitly reserving environment variable changes for that sibling.

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

Usage Guidelines5/5

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

It explains the partial-update contract directly: send project_id and only fields to change, with omitted fields retaining current values. It also names an explicit exclusion and alternative ('Environment variables are not changed by this tool; set_env_vars does that') and states the read-write token requirement.

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