publ betaReference (MCP guide)
Open publ console

Read, plan and save SEO metadata

# Read, plan and save SEO metadata

## Observe the selected channel

Call [channel_seo_get](../tools/publ_channel_seo_get.md) with the exact authorized channel:

```json
{"channelCode":"selected-channel-code"}
```

A numeric record can return stored observations with a revision. Keep that distinction when explaining the current state. Neither reader result establishes an active domain or permission to save.

## Plan the requested change

The [writer](../tools/publ_channel_seo_apply.md) independently requires an ACTIVATED connected domain, stable SEO/domain observations and configured recache/DNS services. Image replacement also requires upload services. Use the fresh revision, preserve omitted fields and explicitly request a dry run:

```json
{
  "channelCode":"selected-channel-code",
  "requestId":"seo-guide-plan-001",
  "expectedRevision":"0000000000000000000000000000000000000000000000000000000000000000",
  "description":"A description of this site.",
  "dryRun":true
}
```

Replace placeholders before use. Domain404 is unverified, not absence. The action_required result retains the exact SEO console destination and explains account-level domain registration/selection, channel connection and ACTIVATED status. No domain is connected by this tool. Inspect the returned plannedStages and noop. Planning cannot prove a future service write or authorize a change not requested by the user. To perform an authorized change, use the same desired fields and valid current revision with dryRun:false. That defaults to false if omitted.

Title and description limits are 40 and 80 characters. Empty strings are rejected; text is not trimmed. An image is original PNG/JPEG bytes encoded as canonical base64, at most 5 MiB; URLs, file paths, data URLs and clear-image requests are unsupported. The image is structurally checked, not rendered.

## Interpret partial completion

The workflow optionally uploads, saves the selected metadata fields, reads back preserved fields, then requests recaching and reads again. A failed recache does not undo the save; an uploaded object is not automatically deleted. Report the actual record, phase and separate save/cache acknowledgements. A no-op or readback-only recovery can have a completed record without a save acknowledgement.

Retain taskId/taskType channel-seo and the exact original input. Status is historical. Resume can continue untouched stages, but grant-sent/upload-sent and recache-sent remain held; save-sent is only reconciled by readback and is not sent again. An unstarted image task needs the original apply and identical bytes, because image data is not journaled. Follow the writer's phase table rather than creating another request ID to force a retry.

A success means bounded metadata confirmation and the reported cache-request acknowledgement. It is not confirmation of browser-visible metadata, social preview, object visibility, cache freshness, crawler indexing or a deployed client integration. Those require separate evidence.

After a successful read, keep its returned revision for the next authorized request. External token replacement still requires a fresh read and review; never rewrite an uncertain task to make it fit new credentials.

SEO retains its independent domain prerequisites and unverified positive-write scope.

This corrects the earlier strict-metadata boundary failure shared with widget uploads.