update_portal_settings
Idempotent
Change a portal's settings: name, subdomain, locale, theme, colour, sign-in type (the login window), whether people can register themselves. The answer says where the menu is now (menu) and whether the change moved it (menu_moved), who gets into the portal now (access), whether your call changed that (access_changed) and whether people can create their own accounts (self_registration).
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": {
"app_id": "<app_id>",
"portal_id": "<portal_id>"
},
"name": "update_portal_settings"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name | |
| color | No | The colour: 0=White, 1=Black, 2=Grey, 3=Blue, 4=Green, 5=Orange, 6=Red. In themes 0, 1, 3, 4, 12, 13 0 is a light menu with dark letters, and 1–6 a menu of that colour with white letters. It keeps the theme and the menu's place. | |
| theme | No | The theme, which also decides where the menu is: 0=Standard (menu: a bar across the top), 1=Professional (menu: a narrow strip of icons on the left that opens on hover), 3=Professional Opened (menu: an always-open panel on the left), 4=Wide (menu: a narrow strip of icons on the left that opens on hover), 9=Fullscreen (menu: no menu bar), 11=Carbon dark (menu: a bar across the top), 12=Left list (menu: an always-open panel on the left), 13=Right list (menu: an always-open panel on the right). A theme decides where the menu is, so a theme change can move it. When the person said where the menu must be, that decides the theme: left → 12, right → 13, top → 0 or 11. For colours use `color`: it keeps the theme, so the menu stays where it is. | |
| app_id | Yes | Project ID (from list_projects) | |
| locale | No | en, uk, ru, ... | |
| auth_type | No | The portal's sign-in (the login window): 0=public: anyone with the link gets in, no sign-in; 1=one shared login and password for everyone; 2=sign-in required: each person signs in with their own login and password. The numbers are for this call only: never show them to the person. A sign-in mode does not let people register themselves (create their own accounts): that is this tool's `self_registration`; accounts are otherwise made by inviting people (invite_portal_user). | |
| portal_id | Yes | Portal ID (from list_portals or describe_project) | |
| subdomain | No | The subdomain without .quintadb.com | |
| self_registration | No | true = a visitor can create their own account on the portal's login page; false = accounts only by invitation. Pass true ONLY when the person asked for exactly this — a request for «login» or «a login window» is not one. false is what «keep outsiders or non-members out» and «nobody may register by themselves» ask for. |