Claim a batch of marketplace items (skipping any already-owned) and compose the apply_operations payload that will place them into the current room. For protected marketplace assets, resolves the runtime CDN GLB through the room build inventory/build-items endpoint; this may attach selected item ...
AI agents use place_marketplace_items 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 |
|---|---|---|---|
items | array | Yes | Items to place. The new room item IDs are returned by apply_operations as ids_created — match them by 'role' to wire logic. |
roomId | string | — | Room id used to resolve protected marketplace asset URLs through get_room_build_items. Falls back to PORTALS_ROOM_ID env. |
Parameters from the server's own tool schema.
The tool claims marketplace items and attaches them to room inventory, which are write-side-effect operations (modifying ownership/inventory state). It does not execute the placement itself (returns an operations array for apply_operations to handle), and claiming items does not involve direct financial transactions. The inventory attachment is a reversible write action.
From the tool's definition 'Claim a batch of marketplace items (skipping any already-owned) and compose the apply_operations payload that will place them into the current room' and 'this may attach selected item IDs to the room inventory'
Attacks that exploit this kind of access
Claim a batch of marketplace items (skipping any already-owned) and compose the apply_operations payload that will place them into the current room. For protected marketplace assets, resolves the runtime CDN GLB through the room build inventory/build-items endpoint; this may attach selected item IDs to the room inventory but never downloads or reuploads user assets. Does NOT place scene objects by itself — returns an operations array. The caller (you) MUST then call apply_operations with that exact array to actually place the items. Use this immediately after the user picks items in an asset_picker and approves a plan_preview. 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.
place_marketplace_items accepts 2 parameters: items, roomId. Required: items. 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 place_marketplace_items: 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.
place_marketplace_items 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 place_marketplace_items 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 place_marketplace_items. 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.
place_marketplace_items 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 →