Tutorial: publish safely with ArchyPress MCP permissions and verification

Oct 07, 2026 • ArchyPress

Three manuscript stages on an editorial desk progress from rough notes to a reviewed article with a gold approval seal.

A connected assistant should be able to help with publishing without making the release decision for you. This tutorial turns that principle into a repeatable workflow with concrete tool checks.

Use it after configuring ChatGPT, Copilot, Codex or another supported MCP client. The same editorial checks apply whether the connection uses OAuth or a publisher key.

Five publishing stages: identify the workspace, create and inspect a draft, review it, explicitly approve the intended post, and verify the public result.

1. Identify the channel and workspace

Call archy_blog_whoami before creating anything. Confirm the publisher channel, workspace and roles. A valid credential for the wrong workspace is not a successful setup for your task.

Next call archy_blog_list_posts with limit 1. This checks the content API beyond the authentication layer. Stop if it returns an error instead of inspecting or editing unrelated content.

Verify my ArchyPress publisher and workspace, then list one post. Do not change any content until I confirm the identity.

2. Understand the two permission gates

A publisher channel owns the author identity and backend roles. An OAuth app connection references that channel and carries its granted scopes. It is a revocable access path, not a new author.

A scoped app connection references an existing publisher; both OAuth scope and channel role must allow the requested operation.

publisher:read permits hosted reads.
publisher:write is required for hosted writes.
Draft creation requires a writer/admin publisher role.
Direct publication requires the publisher's admin role.

Do not ask for admin merely to fix a read failure. Do not assume a write scope overrides a channel role. Diagnose which gate rejected the operation and adjust only the permission your workflow needs.

If a client omits scopes, the pending compatibility fix defaults to read-only. Reconnect with explicit write scope when you intentionally move from reading to creating content.

3. Create one purposeful draft

Use archy_blog_create_draft for content you compose, or an available AI-draft tool for a topic-driven starting point. Give the post a distinctive title and record the returned ID.

Create a draft titled “Getting started with our release.” Explain who it helps, one working example and the limitations. Return its ID and read it back. Do not publish.

For structured content, use archy_blog_compose_doc and the body helpers instead of inventing arbitrary document nodes. Retrieve the saved post to confirm that the intended body persisted.

If creation times out, inspect the post list before retrying. A failed acknowledgement does not prove the first create operation made no change. Subsequent revisions should target the known post ID.

4. Review the artifact the reader will see

Verify product claims and any version-sensitive commands.
Open every link; readers should not need access to a private repository.
Check the title, excerpt, author, categories and URL slug.
Add useful media with meaningful alt text.
Inspect the saved body, not only the assistant's chat summary.

A feature image sets context. An inline diagram should explain a real relationship or sequence. Do not present invented interface mockups as product screenshots, and do not let decorative media replace essential steps.

Preview before publication where available. Confirm that code examples contain placeholders, not real credentials. Check that internal workspace information has not slipped into a public tutorial.

5. Make publication an explicit decision

Publish the reviewed article with ID <post-id>. Do not publish any other post. Then read it back and return its published status and public URL.

The approval should identify the exact article, not authorize a broad batch of writes. Keep tool approval controls enabled, and inspect any proposed payload that differs from the reviewed draft.

After archy_blog_publish succeeds, call archy_blog_get_post. Confirm the status is published. Then open the public URL and inspect the title, body, images and links.

MCP HTTP 200 can contain a tool error. Read isError and the payload. The database's published state and the rendered public page are complementary checks, not interchangeable proof.

6. Diagnose errors at the correct boundary

A 401 at the MCP endpoint can mean missing, expired or revoked credentials. Reconnect or rotate the intended credential. Do not reuse an authorization callback from an earlier login attempt.

A 403 can mean that scopes or roles do not permit the action. A downstream hosting-protection response points to application routing, not an identity you should recreate.

Operators should route content requests through the configured public application origin. Turning off deployment protection is not a suitable substitute for fixing credential-bearing request routing.

7. Revoke the access path, not the publisher

In Admin → Publishers, find the relevant OAuth app connection beneath its channel and select Disconnect. Its access and refresh tokens are revoked; unrelated keys and the publisher identity remain separate.

For static-key clients, revoke or rotate the key using its own controls. A new key must be stored securely in the client; never paste it into a public article or commit it to source control.

Test revocation using a dedicated test connection. Verify its tool calls stop working and its refresh token cannot recover access. Do not disconnect a colleague's active integration as a test.

A useful definition of done

You know which publisher performed the action, the reviewed draft matches the saved body, publication was explicitly approved, the public page is correct, and the connection can be revoked independently.

That is where MCP earns its place in a publishing workflow: fewer manual handoffs without giving up the team's ownership of accuracy, voice or release timing.