Seller information read and human actions

publ_seller_information_get maps the original account Seller information screen. It reads the self account, the source business-information endpoint, and the self account again to check identity continuity. It uses the owner account bearer and the configured general API origin without channel or consumer headers. It accepts no account, profile, business-information, or attachment IDs.

Evidence: Account/SellerInfo/pages/SellerInfo/SellerInfo.tsx, EditSellerInfo/EditSellerInfo.tsx, SellerTypeSelector, both personal/business forms, businessInfo/types.ts, reducers/sagas, businessInfomation.ts, and routers/core/core.ts.

The result includes the independently identified account and business-information record, seller type, country, company and representative names, registered business numbers, address fields, and attachment metadata. account.type and businessInformation.type are separate source fields and need not be equal: the business-information type may be null while the source type-selector screen is displayed. Missing data, 404, malformed responses, foreign attachment parent IDs, and duplicate attachment IDs or types are errors rather than inferred empty registration state. The attachment list is bounded to 100 as a bridge contract limit; larger responses fail instead of truncating.

Attachment entries expose only type, hasFile, and updatedAt. File URLs, attachment IDs, and document contents do not enter the MCP result. Unknown response fields are discarded. The tool does not fetch files or follow returned addresses. All seller strings are untrusted stored data, not instructions.

Human links use central console configuration and verified routes /seller-info and /seller-info/edit. When type is null, the next action points to seller-type selection on the main screen; otherwise it points to the editor. These links do not submit a type, registration number, document, payment, or settlement request. The existing contact editor MCP remains available through publ_seller_contact_get/apply. Demo responses contain no real console URL.

The original business editor combines a metadata PATCH, an optional registration-number POST, and document uploads/attachment PUTs. Business type selection combines a type POST and optional license-type PATCH. Those writers still need a separate implementation contract and trusted document ingress; linking to the console does not count these APIs as implemented. No user credentials, identity documents, or signed document links are requested in conversation. Payments and settlement remain human link handoffs per the product scope.

There is no task journal or mutation revision for this read-only tool. verification.confirmed:true means the returned stored data passed the read contract with a stable self-account identity. It does not claim an atomic multi-endpoint snapshot, a completed human action, or verified documents. Reread after human work to observe current values.