Package MCP-generated concepts for client review

Package the decision, not just the generated files

A client-review package should make a bounded decision easy: which concept is being considered, what it is intended to test, what evidence accompanies it, and who may approve the next step. Put only selected proofs in the package. For each proof, show a stable concept ID, intended placement, model and provider disclosure, generation status, known defects, accessibility note, and a plain-language question such as “Approve this composition for deterministic finishing?” Keep rejected explorations in an internal archive so the client is not asked to reconstruct the creative team's filtering work.

OfflineCreator's current public MCP page says an agent can inspect available models and use the Studio generation workflow, while the version-pinned @offlinecreator/mcp 0.1.2 README documents separate tools for model listing, credit lookup, generation, upload, status, waiting, completed-output retrieval, cancellation, and recent jobs. Those operations can produce and retrieve evidence for a handoff. They do not by themselves create a client portal, collect comments, route approvals, or certify a deliverable.

Choose a package shape that matches the review decision

A vendor-published ReviewStudio customer story reports that creative agency Neoscape values contextual markup and one central place for comments and notation. Treat that as a named agency anecdote, not an independent benchmark or proof that the same result applies elsewhere. Its useful design signal is narrower: the file bundle and the review record solve different problems. A local folder can preserve review inputs, while the governed review system should preserve client identity, comments, versions, and approval history.

Do not turn a ZIP filename, downloaded output, email reply, or chat reaction into approval. Define the allowable decisions in the cover note and record the final disposition in the accountable system. If the client needs live comparison, annotations, reminders, access controls, or multi-stage approval, select a tool that actually documents those features instead of implying that MCP generation provides them.

Concept selection

Contact sheet plus one-page rationaleShow a small, numbered set at the same viewing size, identify the variable each concept tests, and ask the client to select, reject, or request one bounded revision.

Production authorization

Selected proof plus manifest and caveatsInclude the approved source brief, model and provider disclosure, prompt record, output identifier, cost record, rights notes, defects, finishing plan, and the named human approver.

Formal client feedback

Use the governed review systemUpload the package to the agency's existing proofing or project tool so comments, versions, permissions, and sign-off remain in the system chosen for client accountability.

Preserve the MCP job trail without inventing provenance

Record the model visible at generation time, provider disclosure, expected credit cost, prompt or prompt hash according to the engagement's confidentiality rules, returned generation ID, completion state, retrieval time, local filename, and a checksum calculated after download. OfflineCreator states that web, MCP, CLI, and API generations share one account credit balance and published per-model costs, and that the selected provider and cost are visible before generation. Capture those fields as observed project facts; do not infer speed, quality, licensing, or client acceptance from them.

Current MCP tool guidance says tools are model-controlled, does not mandate one user-interface pattern, and recommends a human able to deny invocations, clear invocation indicators, confirmation prompts, input and result validation, timeouts, and tool-use logs. Place the human gate before a paid generation and again before the package leaves the agency. A tool-call log can support an internal audit trail, but it is not the client's approval record unless the engagement explicitly defines it that way.

Build one inspectable local review bundle

For a concrete example, create a folder named `spring-launch-concept-review-v01`. Put a short `README` at the root with the decision requested, due date, approver, confidentiality note, and instructions for returning feedback. Add a `proofs` folder containing only `concept-a-square.webp`, `concept-a-vertical.webp`, and a two-up contact sheet. Add a `records` folder with `manifest.json`, `review-checklist.csv`, and `disclosure.txt`. Keep source prompts or restricted inputs outside the client bundle when the agreement does not authorize their disclosure.

In `manifest.json`, give every proof the same stable concept ID used in the contact sheet. Record its relative filename, intended channel and ratio, model, provider, generation ID, generation status, retrieved-at time, local checksum, human reviewer, approval state, defects, and required finishing. In the checklist, separate factual checks from taste: source rights, product and claim accuracy, embedded text, brand fit, crop safety, accessibility, disclosure, and final decision. This is a proposed project manifest, not a cryptographically signed Content Credential.

Root note

README with one decision requestExplain what the client is reviewing, what remains unfinished, where comments belong, and what approval authorizes.

Proof set

Selected, numbered, placement-labelled filesUse consistent filenames and viewing sizes; exclude discarded generations and avoid presenting a contact sheet as final production art.

Project record

Manifest, checklist, and disclosureKeep generation facts, human review, caveats, and disposition inspectable without claiming tamper-evidence.

Reject a package that hides unfinished work

C2PA implementation guidance describes a standard C2PA Manifest as a structured provenance object with required assertions and discusses digitally signed claims and lifecycle events. An agency-created `manifest.json` is useful operational metadata, but it is not a C2PA Manifest merely because it uses the same noun. Make that distinction explicit so a reviewer does not mistake a readable project record for cryptographic provenance.

Accessibility belongs in the package rather than at the end of production. W3C guidance says informative images need text alternatives conveying their essential information, decorative images should use null alternatives, and images containing important text need equivalent words in the alternative. Draft context-specific alt text for each selected proof and mark it for human review; a visual description that ignores the concept's purpose is not enough.

Good fit

A small proof set for one named decisionThe agency can disclose generation facts, identify defects, name a reviewer, and keep formal comments in an accountable channel.

Revise before sending

The outputs contain uncertain copy or product factsReplace generated lettering and verify claims, identity, rights, and required disclosures before asking a client to approve production.

Use another delivery method

The package needs security or provenance controls it does not haveDo not label an ordinary JSON record tamper-evident, call an expiring link an archive, or send confidential source media through an unapproved channel.

Continue from the client's next decision

Return to the creator-use-case directory when the output type is still open. Use the campaign-asset approval page when the immediate task is verifying claims, rights, brand fit, costs, and disclosure before release. Use the generated-media accessibility page when the concept is selected but still needs context-specific text alternatives and presentation checks. These routes keep this page focused on packaging selected proofs and their decision record.

Evidence boundary for client-deliverable packaging

Keep community material out of this page's practitioner guidance unless it identifies the practitioner, describes the review behavior, and survives source-level verification. The ReviewStudio page supplies one named, vendor-published Neoscape account about contextual markup and centralized comments; use it only for that narrow workflow signal. Do not generalize it into evidence of MCP packaging practice, agency-wide adoption, or a repeatable outcome. Treat unavailable retrieval channels as unresolved gaps and keep channel-level diagnostics in the research brief rather than converting them into reader-facing claims.

Use the current OfflineCreator pages only for documented generation operations, provider and cost visibility; use the MCP specification for tool-control guidance; use the qualified Neoscape story for its named agency observation; use C2PA guidance for provenance terminology; and use W3C guidance for image alternatives. Verify collaboration, client-portal, shared-seat, approval-routing, persistent-link, quality, reliability, latency, certification, legal, satisfaction, and campaign requirements separately before adding any such claim.