Update ONLY a room's scene settings (lighting, skybox, fog, postprocess, movement, avatars, voice chat, etc.) without touching items, logic, tasks, or quests. Uploads a settings-only payload to the room scene store; the backend writes the settings blob in place and live-reloads it, leaving every ...
AI agents use set_room_settings to create or update resources in Portals — usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Portals environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
roomId | string | — | Room ID to update. Falls back to PORTALS_ROOM_ID env variable if omitted. |
settings | object | Yes | Complete settings object exactly as returned by get_room_data under `settings`. Must include roomBase and roomSettingsExtraData (a JSON string). The backend ove |
Parameters from the server's own tool schema.
This tool creates or modifies data (room scene settings) in a reversible manner. It does not execute arbitrary code, trigger external operations, delete data irreversibly, or move money. The modification is scoped to settings only and explicitly avoids corruption of items/logic/tasks. While it affects a shared room environment, the changes are configuration updates that can be reverted, placing it squarely in Write.
From the tool's definition Tool description states it 'Update[s]' room settings and 'Uploads a settings-only payload' that 'the backend writes...in place and live-reloads it'.
Risk signalsBulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
Update ONLY a room's scene settings (lighting, skybox, fog, postprocess, movement, avatars, voice chat, etc.) without touching items, logic, tasks, or quests. Uploads a settings-only payload to the room scene store; the backend writes the settings blob in place and live-reloads it, leaving every item untouched. This is the SAFE way to change lighting/skybox/fog/etc. — unlike set_room_data it never round-trips items, so it cannot corrupt item positions or extraData. Provide the COMPLETE settings object: read it from get_room_data (the top-level settings field), modify the keys you need (e.g. parse settings.roomSettingsExtraData, edit lightValues/fog/postprocess/skybox*, re-stringify it), then pass the whole settings object back. It is categorised as a Write tool in the Portals MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
set_room_settings accepts 2 parameters: roomId, settings. Required: settings. The full parameter table on this page comes from the server's own tool schema.
Register the Portals MCP server in PolicyLayer and add a rule for set_room_settings: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Portals. Nothing to install.
set_room_settings is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the set_room_settings rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for set_room_settings. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
set_room_settings is provided by the Portals MCP server (portals-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Every MCP server has a record like this.
Type a name, get the same breakdown: verified identity, auth posture, risk grade, capabilities, recommended policy.
Teams ship this data inside their own products. See what a licence covers →