Configure monetization and choose financial reads
Membership and Point product configuration use the composed writers below. monetization_get and explicit console handoffs remain readers/navigation; they do not perform those writes. Inspect the connected endpoint's operation schema before using a later method.
| Need | Operation and scope |
|---|---|
| Activation, plan and base currency | monetization_get without consoleAction reads the overview. Activation and service-plan changes still use its human console actions. |
| Membership card/benefits and installed-feature associations | memberships_get observes current choices. membership_create composes a new membership, including supported original artwork; membership_update changes supported existing metadata/access. Creating a membership does not create a sale product. |
| New membership sale/subscription product and creation-time price | membership_product_create uses the current parent membership revision and a complete free, paid-once, subscription or eligible coupon offer. Source currency, period, purchase-method and coupon restrictions apply. It does not purchase or charge funds. |
| Existing membership product presentation, selling state or extension settings | membership_product_apply uses the exact observed product page/filter and productPageRevision. Supported actions are edit, selling-state and extension. Base title, price, type and period remain source-locked; supported extension pricing is a separate setting. |
| Channel Point policy switches and localized provisions | channel_point_settings_apply uses policy-read configurationRevision for switches or provisionsRevision for human-reviewed text. These are separate input forms; provision saves require review of the exact dry-run contentHash. |
| Existing WEB Point charge-product display name, bonus or visibility | channel_point_product_apply uses productsRevision from the exact current products page. Base price/quantity remain unchanged. Creation, deletion and onboarding are not implemented by this writer. |
| Point presets, policy/products, issuance, ledger or withdrawals | channel_points_get uses the selected view and source service. channel_points_handoff remains optional navigation for supported configuration screens and the human route for financial actions. |
| Settlement records, account, balance, availability or document reference | settlement_get observes its selected view under plan/business/visibility/currency gates. settlement_handoff prepares a human action. |
| Payment-provider/method list | monetization_get with view:payment-gateway performs separate scoped issuer authorization and reads provider records. See the provider guide. |
| Sales summary data | sales_overview_get requires MANAGE_SALES_OVERVIEW. |
| Order/refund records | orders_get / refunds_get require MANAGE_ORDER and their own service prerequisites. Sales totals and human guidance do not substitute for those reads. |
Read, configure and recover
Membership and Point configuration require the selected channel's OWNER or MANAGE_MONETIZATION delegation. A browser-approved MCP target does not replace these current publ permissions. Product creation uses the parent membership revision; editing an existing membership product uses its product-page revision. Point switches, provisions and products each return a different revision. Keep the selected channel, page/filter, product identity and revision together; they are not interchangeable.
Use a fresh dry run to inspect the composed request. It does not create a task or prove a saved change. Preserve the original requestId, target and exact business input after dispatch. The linked writers document their own task types and read-only recovery: an uncertain sent effect is not automatically repeated. A completed replay is historical; use the matching reader for current values. A new product can remain as a record after selling is suspended; suspension is not an undo of creation.
Configuration is separate from purchase/payment execution, refund approval, withdrawals, settlement execution and service billing, which retain their human-console boundaries. A product price can be configured where its source wizard permits it without implying payment execution. Do not infer legal adequacy from stored provision text or visitor access from saved membership associations.
Human destinations and financial observations
Use an explicit monetization_get.consoleAction or memberships_get detail.consoleAction only when the person needs that source screen. Existing creation, edit, extension and selling-state handoffs remain navigation choices alongside the supported writers, not a requirement to leave all product configuration manual. Product-list handoffs require the exact observed page/filter. A returned link grants no access, submits no action and proves no browser completion.
Monetization navigation additionally requires MANAGE_SALES_OVERVIEW for delegated sales and MANAGE_ORDER for delegated orders/refunds, on top of MANAGE_MONETIZATION. Dedicated sales and order/refund readers independently require their own permissions. Settlement uses MANAGE_SETTLEMENT. Follow one returned humanActions/readActions recipe rather than inventing a modal URL. Raw monetary strings, raw CP, missing values and currencies retain their reader-specific meaning; unavailable data is not zero balance or eligibility.
Bounded observation failures may still yield guidance for explicitly supported unselected screens after access revalidation. The payment-provider read does not use that fallback. Selected membership/product/ticket checks, authentication and context failures remain strict. After a person acts, repeat the relevant reader. The unified hosted interface calls the selected business name through execute.operation with an approved target; its two public tools are not a business-feature completion count.
Orders and refunds source extension
Their consoleAction options remain human navigation. Financial approval/rejection, pass revocation and CSV exports stay in the console.
Selected membership product serial keys
The serial-key guide describes those reads and manage-coupons guidance. Key issuance, withdrawal, redemption and CSV generation remain separate human actions. These limits do not exclude the product creation/configuration writers above.
Exact product-list human actions
The product-list workflow retains page/limit/isDeactivated for manage-extension, activate-product and deactivate-product navigation. The source modal or bulk control requires manual row selection, and alreadyMatches is an observed state rather than a mutation receipt. Use membership_product_apply for the corresponding supported MCP configuration.
Diagnose an unverified membership display list
On a list schema failure, fixed field names, coarse types and bounded issue paths may explain what could not be parsed without returning values or unknown keys. The result remains DISPLAY_RESPONSE_UNVERIFIED with no resolved target. No extra read, retry or write is made, and strict validation stays unchanged.
This is a diagnostic candidate, not a correction of the existing actual list failure. Runtime deployment, a coordinated repeat of the authorized request and source comparison remain separate.