Account profile and seller contact workflows

Source: It does not implement login, a hosted user database, or a replacement publ console.

Use each screen's get tool before saving, copy its revision, and retain the same request ID and input after an uncertain outcome. dryRun:true validates and returns the proposed values without a save, credential refresh, or durable task. A no-op verifies current values and completes without writes. The two revisions are intentionally not interchangeable.

Input rules

Account nickname follows the source form: 2–20 Korean letters or jamo, Latin letters, digits, or underscores, without spaces or leading/trailing underscore. It is neither a site title nor a manager login name. Image URLs, target IDs, demographic fields, and credential fields are rejected by strict input schemas.

Seller contact requires the complete form. The name is trimmed, 1–30 characters, and follows the source Korean-syllable/Latin/whitespace pattern. The phone is trimmed and contains 6–12 digits, retaining leading zeroes. countryCode is the source option value: obtain options using includeContactCountries:true; 746 is South Korea's publ option, whereas +82 is a calling prefix and is rejected. Clearing required fields is unsupported. A phone-only change preserves the name and sends only the changed phone fields.

{
  "requestId": "account-nickname-001",
  "expectedRevision": "COPY_ACCOUNT_PROFILE_REVISION",
  "nickname": "SiteOwner_2",
  "dryRun": true
}

{
  "requestId": "seller-contact-001",
  "expectedRevision": "COPY_SELLER_CONTACT_REVISION",
  "contact": {
    "name": "Site Owner",
    "phone": {"countryCode": "746", "number": "01012345678"}
  },
  "dryRun": true
}

The revision strings above are placeholders; replace them with the matching get response before calling the tool. Do not submit passwords or tokens through MCP.

Save, refresh, and recovery

Both saves use the credential connection lock and a private task journal. A task binds the connection ID, owner seller ID, main profile ID, screen scope, input fingerprint, and self-account identity. The bridge writes the sent checkpoint before HTTP and checks current values before the send. The source has no conditional-write token, so this does not eliminate changes between the last read and the save.

Profile save stages are: fresh account/profile read → nickname PUT → account/profile readback → durable refresh checkpoint → account refresh → account/profile readback. Contact save stages are: self-account read → changed-field PATCH → self-account readback. Source successful 2xx mutation acknowledgements are accepted; final confirmation requires matching values and preserved screen fields. Response timestamps are not compared because saves can change them. No automatic rollback is attempted.

An unknown save is never repeated. Resume reads the same target and advances only if the expected state is visible. An explicit rejection may be retried with the original task if the original screen state still matches. An unknown refresh is held until trusted recovery changes the private credential version for the same owner connection; the bridge does not send that refresh again. Successful refreshed credentials must preserve seller/main-profile identity before private atomic persistence. Omitted channel credentials are preserved; an explicitly returned channel bundle updates matching entries without deleting other stored channels, following the source refresh loop. Concurrent changes to the credential file prevent refresh persistence.

success plus verification.confirmed:true means matching stored values were freshly observed, not that the bridge caused them or that every browser session's effective permissions were validated. Completed apply/resume results are explicitly historical and have verification.confirmed:false; the get tool supplies current values. Status authenticates the self account before returning historical task data. Account, connection, profile, or screen changes block task disclosure and continuation.

Task files contain account identity and contact/profile values needed for conflict detection and recovery. They contain no passwords, raw tokens, or profile demographics. The existing owner-only state directory and file permissions apply. A future hosted integration must supply tenant-isolated ports, credentials, stores, and retention; the current stdio runtime does not provide multi-user isolation.

Human console work

Links are generated from the central console origin and source routes /account-info and /seller-info/edit-contact-info. No alternate console host is hardcoded. Demo results contain no real console link. The human follows the original publ console; account email remains read-only. The separate hosting UI is for MCP login, connection instructions, and account/channel selection, not these publ business-operation forms.