Change the state of a task/quest or activate an effector in the live game via the IFrameBridge. Two modes: (1) Provide effectorId to directly activate an effector (optionally with roomItemId for faster lookup). (2) Provide taskName and targetState to transition a task to a new state. TESTING TIP:...
AI agents invoke change_task_state to trigger actions in Portals. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
delay | number | — | Delay in milliseconds before the state change takes effect. Default 0. |
taskName | string | — | The task name as defined in the room's logic system. |
effectorId | string | — | Effector ID to activate directly. If provided, targetState is ignored and the effector is fired immediately. |
roomItemId | number | — | Room item ID to scope the effector lookup. Used with effectorId for faster direct lookup. |
targetState | string | — | The target state or state transition for the task. Required when using taskName. |
Parameters from the server's own tool schema.
This tool executes operations in a live game environment (via IFrameBridge) that cause state transitions and trigger reactive logic. While not destructive in a data-deletion sense, it irreversibly modifies game state and task progression. The effects are dependent on caller-supplied arguments (effectorId, taskName, targetState), making it an Execute-category tool.
From the tool's definition 'activate an effector in the live game' and 'transition a task to a new state' indicate the tool triggers external game state changes.
Attacks that exploit this kind of access
Change the state of a task/quest or activate an effector in the live game via the IFrameBridge. Two modes: (1) Provide effectorId to directly activate an effector (optionally with roomItemId for faster lookup). (2) Provide taskName and targetState to transition a task to a new state. TESTING TIP: Create hidden test helper items with known effector IDs (e.g. 'test-ready-up') that call SetVariable to trigger reactive logic. Then use this tool to fire those effectors programmatically, followed by get_runtime_data and render_scene to verify the results. It is categorised as a Execute tool in the Portals MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
change_task_state accepts 5 parameters: delay, taskName, effectorId, roomItemId, targetState. 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 change_task_state: 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.
change_task_state is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the change_task_state 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 change_task_state. 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.
change_task_state 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 →