Permissions and safe operation

The Bluestone PIM product MCP server acts with the organization access and permissions of the signed-in user. An assistant cannot use a tool successfully unless that user is allowed to perform the underlying operation, but a permitted tool call has the same operational effect as the user performing that action.

Treat every non-read-only tool call as a real change. Creates, updates, assignments, publication changes, archive actions, deletions, and bulk operations can affect shared organization data.

Permission and organization scope

• The authenticated session resolves an organization, and data access stays within that session's scope.
• Existing Bluestone permissions determine which records and operations the user can access.
• Read and write access are not interchangeable. A user who can inspect a record may still be unable to update or delete it.
• A denied operation may indicate missing permission, the wrong signed-in user, the wrong organization, or an unavailable target. Do not respond by trying broader or more destructive tools.
• Use a dedicated user or role with only the permissions needed for the task when practical.

The tool reference provides a searchable summary of the available operations. Your MCP client displays each tool's input contract.

Use a read-plan-confirm-execute-verify loop

1. Read

Start with read-only discovery. Resolve internal IDs, product numbers, contexts, catalogs, categories, relations, and current values from returned data. Never ask the assistant to infer an ID or context from a similar name.

Find product <product-number> and summarize its current attributes. Use read-only tools only. Show the record ID and context you used.

2. Plan

Ask for a proposed change in plain language before any write. The plan should identify:

• The exact target records and organization context
• Existing values and proposed values
• The number of records affected
• Whether the operation creates, replaces, detaches, archives, or deletes data
• How the result will be checked

A written plan is not a server-side dry run or transaction preview. It is a review boundary before the real tool call.

3. Confirm

Require explicit confirmation immediately before the write. Make the confirmation narrow enough that it cannot be reused for a materially different target or action.

Do not make changes yet. Show the exact product IDs, current values, proposed values, and the tool you would call. Wait for me to confirm this specific change.

Reconfirm if the target list, values, tool, or scope changes after your approval.

4. Execute

Permit only the reviewed operation. For a large change, start with one representative record in Test and inspect the result before continuing. Do not split a denied bulk operation into repeated single-record calls to bypass a permission or safety boundary.

5. Verify

Use read tools to retrieve the affected state again and compare the actual result with the approved plan. If the operation returns an asynchronous job identifier, inspect that job until it reaches a terminal state before treating the change as complete. If the connection has no read tool for the affected state, verify the result in Bluestone PIM or another trusted read surface; otherwise report the action as unverified instead of claiming it completed successfully. For important changes, also inspect available history where relevant.

Extra safeguards for high-impact actions

Use heightened review for operations that:

• Delete a catalog node or another structure that may contain descendants
• Archive or update multiple products
• Replace a collection, such as labels or attribute values
• Remove associations between products, assets, categories, labels, variants, or tasks
• Change asset publication state
• Create or complete uploads
• Assign or complete tasks on behalf of users

Before one of these actions, require the assistant to report the operation's effect, target count, identifiers, and verification method. Export or otherwise retain a recoverable record of current values when the change is difficult to reverse.

Safe prompt patterns

Read-only investigation:

Find products missing the Color attribute. Do not change anything. Return the matching product IDs, current context, and total count, then propose a remediation plan.

Controlled update:

Inspect product <product-number> and the Color attribute definition. Propose the smallest update needed, including the exact IDs and value. Do not call a write tool until I confirm.

Destructive-operation boundary:

Do not archive, delete, detach, replace, publish, or complete anything in this task. If one of those actions appears necessary, explain why and stop for confirmation.

Platform-guidance research:

Search Bluestone platform guidance for catalogs and categories. Use guidance tools only and cite the retrieved page titles or identifiers in the answer.

Client and team controls

Prompt instructions are useful but are not a substitute for access control. Combine them with:

• Least-privilege Bluestone permissions
• Test-environment testing
• Client approval prompts for tool calls, where supported
• Narrow task scope and explicit target lists
• Human review of significant changes
• Sign-out and credential removal on shared devices

See Common workflows for guided task patterns and Troubleshooting and limitations for access failures.