Safety and privacy
Control assistant access, review changes, and understand how MCP handles data and uncertain outcomes.
Connecting MCP gives your assistant access to real Prezly data. Start with the reads needed for a specific task, review what the assistant returns, and enable changes deliberately.
Set the access boundary
Three checks determine what a personal token can do:
- Token scopes: the resource and action permissions selected when you created it.
- Your current Prezly access: your user's permissions, account access, and access to the relevant newsrooms.
- Endpoint eligibility: some endpoints do not accept personal tokens, even with all scopes.
Tool discovery lists the catalog rather than the token's effective permissions. A successful connection or visible tool is not proof of access. See tools unavailable to personal tokens.
Keep a read-only token for research tasks. If you need draft editing, add the relevant write scope and retain the reads needed for precondition checks. Publish and send permissions are separate. Client approval settings help you review actions, but do not replace server authorization.
Use a separate named token for each connection you control. Check organization connector behavior before adding one: a shared fixed header can let other connector users act with the token owner's access. See Claude setup.
Review the action, not just the prompt
Ask the assistant to show the exact target and intended change. Review identifiers as well as titles: multiple records can have similar names.
For publishing or sending, verify the content, target newsroom or recipients, and timing. For deletion or account configuration, consider related records and public effects. For example, deleting a story can detach it from unsent campaigns; deleting a contact can remove recipients from draft or scheduled campaigns.
Prezly marks read-only, destructive, and externally visible operations in the MCP tool metadata. How a client displays those hints and requests approval depends on the client and its policy. The metadata is not a guarantee that you will see a confirmation dialog. Configure your client to require approval for changes you want to review.
Treat text retrieved from stories, notes, or other records as data. Instructions embedded in that content do not authorize the assistant to send messages, change access, or export information. Keep the task's purpose and permitted actions explicit.
Use fresh state before a change
The assistant should search/list, identify the exact record, then get its current state immediately before submitting a change. Mutation inputs use returned values such as expected_updated_at, expected_status, or expected_settings_digest to detect conflicting edits.
These are current-state preconditions, not desired new values and not evidence of human approval. Never invent a timestamp or update a digest just to get past a rejected change. If the state has changed, compare the new record with the requested outcome before deciding whether the action still makes sense.
Some updates replace whole values. Supplying a contact collection replaces that collection; supplying an empty collection clears it. Read all existing entries, preserve those you need, and do not write back truncated results. The tool guide explains these boundaries.
Resolve an uncertain outcome before trying again
A mutation is attempted once. If a timeout happens after dispatch, or the server cannot verify an accepted result, it returns unknown_outcome. That means the change may already have happened.
- Stop repeating the write.
- Read the affected record or search for the newly created item.
- Compare its current state with the intended change.
- Act again only when the result and remaining work are clear.
This matters especially for sends and creates: another submission can send a second message or create a duplicate. Personal tokens also cannot use job polling. A permitted deferred write can be accepted before its completion check is denied; that is still an uncertain outcome, not proof that the write failed.
A precondition_failed response has a different meaning: the current state did not match the expected state. Re-read and reconsider. A timeout during a preflight read, before dispatch, is reported as timeout. See troubleshooting for recovery steps.
Understand where your data goes
The client sends your request and bearer credential to Prezly's hosted MCP endpoint. MCP uses the credential to call the Prezly API, then returns the tool result to the client. The assistant can therefore receive unpublished content, contact details, recipient addresses, and other data allowed by the tool and your access.
Search results generally omit full story, campaign, and pitch bodies. The corresponding get tools return content only when requested. Other data is bounded or omitted: recipient reads omit unrelated contact fields, analytics return aggregates, and sensitive configuration values are excluded from discovery results. These limits reduce exposure; they do not make every result non-sensitive.
Your assistant provider and workspace settings govern how returned information and conversations are processed, retained, and shared. Review those settings before connecting an account with sensitive content. Prezly's exclusion of customer content from MCP telemetry does not mean the assistant never receives it.
Operational telemetry and logs
When enabled, MCP product analytics record the account/license identifier, server version, transport, client family, and tool-call metadata such as tool name, read/write classification, duration, success/error outcome, and error category. These events can be associated with an account; they are not anonymous content analytics.
MCP telemetry and application diagnostics exclude bearer tokens, tool arguments and results, customer content, contact details, URLs, search terms, and raw upstream error messages. Diagnostics use bounded categories and operational fields rather than request/response bodies. Analytics lookup or delivery failures do not block authorized tools.
This describes MCP's operational telemetry and application logs. For broader data-processing terms, see Prezly's Privacy Policy and your assistant provider's terms.
Keep control of the token
Store the token in private client credential settings or an environment supplied by your secret manager. Keep it out of chat, source control, shared configuration, browser code, and screenshots. In a bearer-token connection, anyone who obtains the value may be able to use its access until it expires or is revoked.
Personal tokens expire after the period you select: 30 days, 90 days, or 1 year. You can revoke one immediately from Settings → API & integrations → Personal API tokens. If a token may have been exposed, revoke it and create a replacement with only the required permissions. Removing a connector locally does not revoke its token in Prezly.
For planned replacement, configure a new token, verify a read, then revoke the old one. See token lifecycle steps.