publ betaReference (MCP guide)
Open publ console

publ Reference

All toolsView Markdown source

Create a site

Collect the business inputs once, inspect the plan, and create a site through the single creation workflow. Do not reproduce the console's Next/Previous buttons as separate tools.

Establish the account and current choices

If the workflow is unknown, describe account.channel-create with screen_describe. connection_status checks stored connection readiness; successful API reads must still establish actual access. A human prepares the appropriate connection through the runtime or hosted connection flow. Passwords and tokens are not business inputs.

Call channel_creation_options for the intended category:

{"category":"CUSTOM_SERVICE"}

Use returned identifiers when choosing a template or apps. Category choices are listed in the tool Reference. A platform object fixes currency, with KRW used when its currency field is absent; platform:null allows KRW or USD. Template options cover only the first requested page of at most 100 entries.

A blank design uses selected apps or current recommendations. Catalog templates use fixed apps, so normally omit appCodes. If the user intentionally wants no apps, the blank path accepts appCodes:[] with acceptNoApps:true. Current HTTP creation supports default images or an original iconFile on blank/catalog designs. PNG/JPEG is limited to 1,000,000 decimal bytes, with basename and canonical base64; no URLs/paths. Legacy iconAssetId and owner profile-image uploads remain unavailable. HTTP iconAssetId plans stop before reads or writes with UPLOAD_NOT_CONNECTED and the creation-screen link; they do not return PLAN_READY. Use original iconFile bytes only for a new task. Preserve saved task inputs and inspect retained locations before changing course. File-template requests return FILE_TEMPLATE_CONSOLE_REQUIRED before planning or writing, even with dryRun:true. Open the single returned creation-screen link and supply the original .pbchannel file there. Automatic file import remains unimplemented; preserve existing task IDs and uncertain outcomes. See the inline icon contract.

Inspect the creation plan

Call channel_create with dryRun:true. This example deliberately requests a blank site with no apps; use it only when that matches the requested site:

{
  "requestId":"example-empty-site-001",
  "siteTitle":"Example empty site",
  "category":"CUSTOM_SERVICE",
  "design":{"kind":"blank"},
  "appCodes":[],
  "acceptNoApps":true,
  "dryRun":true
}

A new PLAN_READY result contains the planned title, currency, template/apps body, steps, and any required asset IDs (HTTP legacy IDs are rejected before this point). This body is an explanation of the plan, not an alternative input schema to send back. The dry run creates no channel and saves no job, even though it returns a task ID. With iconFile it also returns checked file metadata, never its bytes. It validates upload configuration but does not issue a grant or upload. It does not reserve choices or establish real upload success.

An app's FREE pricing label is insufficient: planning checks installation, monthly, and metered fees in the selected currency. A template containing an unverifiable app or a nonzero/unknown fee returns a human console handoff. Follow the result rather than bypassing it through raw APIs.

Execute and interpret completion

When the plan matches the requested operation, keep all business inputs and the request ID identical and change only dryRun to false. Preserve the returned taskId and taskType:channel-create for interruption recovery. Current options are checked again before creation.

CHANNEL_CREATED with verification.confirmed:true means that a detail read matched the receipt's channel ID/code and the planned title/currency. demo-no-publ-requests is a simulation. Report only returned IDs and links; do not invent a visitor URL.

Hosted creation belongs to the account resource. Working inside the resulting channel requires its own authorized selected-channel resource; the new channel does not automatically expand the original connection's scope.

Recover without creating twice

Use task_status with the original ID:

{"taskId":"example-empty-site-001","taskType":"channel-create"}

This ID is illustrative and must already have a saved job. If only a new dry run occurred, TASK_NOT_FOUND is normal. Status reads progress and does not execute remaining steps. task_resume continues the original saved operation:

  • prepared: recheck current options before any remaining creation steps.
  • creating: the receipt may be lost; automatic resume returns CREATE_OUTCOME_UNKNOWN and never sends another creation POST.
  • created: the channel receipt exists; resume refreshes credentials and reads detail without creating again.
  • done: return the stored historical result; use a fresh channel read for current state.
  • failed: return the saved definite rejection; inspect the original failure before choosing any further action.

Historical jobs without an explicit completion mode do not journal refresh separately, so created-phase resume can repeat refresh. Current default-image jobs have a completionRefresh checkpoint and do not repeat an uncertain sent refresh. Inline-icon jobs checkpoint grant, PUT and refresh: an uncertain sent stage stops without redispatch. An untouched upload needs the original bytes through the identical channel_create call; after acknowledged refresh, a retry performs only readback. The phase table distinguishes these paths. Do not switch connections, alter state, or use a new ID to force another creation after uncertainty. Later errors can leave a successfully created channel in place, and no automatic rollback is provided.

Scope of this guide

These documents explain the implemented input and recovery contracts.

Reference index · Creation options · Creation tool · Common results

Saved record identity

Apply/dry-run replay and task status/resume bind both the saved ID and saved input requestId to the requested task ID. An intact record stored under another lookup key is also refused with TASK_STATE_UNVERIFIED, before business reads or effects. Keep both records for inspection; do not rename/edit them, use the embedded ID or create a replacement task to bypass refusal. Matching tasks keep their existing validation and recovery rules. Connection/authorization checks may still run; this guard is not a complete record schema or current-state verification.