An MCP connection can read or change only what its credential and the site's tools allow. Before connecting a development client, decide which work it should do and which actions need your review.
A request such as “draft this page” describes your intent. It does not make a broadly permitted connection read-only. Use appropriate access restrictions as well as clear instructions.
For connection setup and a first read-only check, see Connecting a development tool to Cedros through MCP.
Understand the controls that apply
Several controls work together:
- The access key identifies the account and carries granted permissions. Keys can also be restricted to particular tools.
- The site's tool checks enforce the required permissions and any additional restrictions on the target data or operation.
- The client configuration controls which tools that client exposes and when it asks you to approve a call.
- The operation's release checks can require a saved revision, preview review, confirmation field, or other prerequisites.
Passing one check does not satisfy all the others. A working connection does not guarantee permission to publish, and a client approval does not override a server denial.
Read-only access can still expose private information. Choose the account, site, and tools with the data the client will receive in mind; “read-only” does not mean “public information only.”
Distinguish tool modes from key permissions
Cedros describes tools using read, draft, and publish modes. These describe the kind of operation; they are not three separate access levels offered when you create a standard site-tools key.
| Operation | Docs example |
|---|---|
| Read: Retrieve information or check state | Read an article or its release readiness |
| Draft: Change saved working state | Update a docs draft or refresh its saved preview |
| Publish: Release content or take another consequential action | Publish, schedule, or unpublish a docs article |
For external MCP calls, Cedros uses the called tool's declared mode. Do not assume there is a separate publish switch you must enable before a permitted publishing tool can run.
Permissions are a separate check. For example, docs read tools require data:pages:read, while both docs draft tools and docs publishing tools require data:pages:write. A key with page-write access may therefore be able to publish as well as edit, subject to the tool's other checks.
The mode name is not a promise that every operation has an unpublished version or can be undone. Read the tool's description and current input schema. A docs draft has a publication lifecycle; a setting update, extension action, or message operation may have a different immediate effect.
The in-site assistant's Tools settings and an external client's MCP configuration serve different clients. Do not rely on the assistant's selected level as the access restriction for an external site-tools key. Review the key's permissions and the external client's available tools directly.
Choose access that matches the work
The setup's Site tools option uses the issuing account's permitted site operations. Assistant conversations is a narrower connection for conversation work, not a general read-only site key.
For a client that should only inspect content, use access limited to the relevant read operations. If you need a stricter permission subset or tool restriction than the setup dialog offers, ask your administrator to arrange it. Do not treat a broad key as restricted because the agent was told to be careful.
A client-side tool allowlist can limit what that client presents, and approval settings can require review before execution. Those settings do not narrow the same key when it is used by another client. Preserve intentional restrictions when updating a connection.
Use separate, clearly labeled keys for separate clients, and keep development and production connections distinct. A task-scoped or other specialized credential should not be used to obtain general administrator access.
Keys carry permissions granted at issuance. Account or membership changes can invalidate access or require a new key; they do not mean you should keep retrying with the old one. For key replacement and revocation, follow Connecting an external AI tool to Cedros.
Revoking a key prevents further authentication with it. It does not undo edits, retract sent messages, or reverse work already accepted by the site. Check those outcomes separately.
Review the exact revision before publishing
For docs, use this sequence:
- Read the intended article and save the requested draft changes. Confirm its content ID, route, and current revision.
- Refresh the saved preview, then open and inspect it. Check the text, links, media, navigation, and appearance at the sizes your readers use.
- When changing a published article, compare the draft with the current live version. Confirm that other recent changes are preserved.
- Read release readiness and resolve the reported blockers. Recheck the preview after any correction that creates a new revision.
- Publish only the reviewed revision after the requested review is complete. Where the tool accepts
reviewedRevisionId, supply the revision you inspected. - Read back the published state and open the public route to confirm the result.
The saved-preview action records the current revision as reviewed. That recorded state is not proof that a person read the preview or approved the wording. Inspect it before treating the review as complete.
If the draft changes after review, the earlier review may no longer match. Reload the article, review the new saved revision, and check readiness again. Do not omit the revision identifier just to avoid a mismatch error.
Docs publishing checks include required content and metadata and a matching saved-preview review. Releasing changes to an existing published entry can also require comparison with its live baseline. A readiness result is useful, but the publish operation still applies its own checks and may fail if the state has changed.
Scheduling is also a release decision. Confirm the reviewed content, destination, and scheduled time; scheduling does not mean the page is already live. See Understanding drafts, previews, and publishing for the content lifecycle.
Treat confirmations and AI review separately
Some operations require a confirmation value in their arguments. For example, an extension capability execution uses execute:<capabilityId> for the selected capability. Discover the actual schema and capability before preparing the call.
A confirmation field makes the requested operation explicit. It is not a substitute for permission, a preview, or the owner's approval, and it does not guarantee a second confirmation dialog will appear. Your client may be able to supply the value and execute the operation in one call.
Review the target and consequences before approving actions such as sending, deleting, restoring, or installing. Use the dedicated operation's preparation and recovery instructions; the docs publishing sequence is not a universal workflow for every action.
Paid AI Review is optional for docs publication. A manually reviewed article can pass release checks without calling an AI provider. Saved previews and release-readiness checks do not require a fresh AI review.
If a current AI review already contains blocking findings, address those findings and check readiness again. Do not clear meaningful blockers merely to make publication available. Request paid generation or review only when you intend to use that service; MCP access itself is not spending approval.
Resolve a blocked action without widening access blindly
The connection cannot authenticate. Check the intended site, credential delivery, expiry, revocation, and any recent account changes. This is a connection problem before it is a publishing problem.
The tool is missing. Refresh authenticated discovery and inspect the client's tool filters. Check the key's access and whether the feature or extension exists on that site. A hidden or unavailable tool is not unlocked by adding its name to a request.
The tool returns permission denied. Read the required permission and ask the administrator to review the intended access. Do not try a generic data tool or another account's key to bypass the denial. See Why can't I see or edit a feature?.
Publishing reports a missing or stale review. Save the intended changes, refresh and inspect the preview, and compare with the current live version where required. Then retry readiness for that revision.
The request timed out or returned an uncertain result. Read the target's current state before repeating the action. A lost response does not establish that a publication, send, or installation failed. Inspect the tool result for errors as well as its transport status.
When asking for help, include the tool name, target, revision where relevant, exact error, and intended outcome. Remove credentials and private data from the evidence.