Recording provenance for MCP-generated media
Retain model, prompt, ratio, provider, and timestamps without inventing cryptographic guarantees.
A practical ledger separates the request record, service record, and asset record. The request record is what the MCP client intended to send. The service record is what the server returned or what the authenticated account history later displayed. The asset record can describe the bytes the operator downloaded. Joining records through a generation ID is useful for operations, but each field still needs an origin label. A prompt copied from the client and a model name returned by the server are not the same kind of evidence.
MCP can carry this data cleanly without defining its meaning for you. The current tools specification allows a server to return arbitrary JSON in `structuredContent`, optionally constrained by an `outputSchema`. Content annotations cover audience, priority, and modification time; they are not a standard generated-media provenance manifest. Clients should validate a declared output schema and preserve the server-produced result before transforming it into a human report.
- Client-observed
- Requested arguments and local send timeUseful for reconstructing intent; not proof that a provider accepted every value.
- Server-returned
- Generation handle, status, result metadataPreserve the original structured result and the schema version used to interpret it.
- Asset-derived
- Downloaded filename, media type, optional operator checksumIf an operator computes a digest, record its algorithm and value and compare only against the intended bytes. This pass computed no media digest and makes no origin, identity, or server-attestation claim from one.
Record a generation ledger, not a vague provenance label
For MCP-generated media, provenance begins as an operational record that connects a tool call to the asset it produced. Keep the exact submitted prompt, selected model, aspect ratio or other format setting, workflow type, disclosed provider, source-media references, generation identifier, and observed request and completion times. Store the final asset reference beside that record. If a field was not returned by the server, mark it as client-observed or unknown instead of presenting it as provider-attested fact.
OfflineCreator Studio’s current privacy policy confirms a narrower documented set: generation content includes prompts, source images, settings such as model, aspect ratio, and workflow, plus generated images and videos. It says generation history and media remain until the user deletes them or closes the account, subject to short backup windows. That account record is useful evidence of what was requested and retained, but the public policy does not say that it is a signed manifest, a content hash, or a cryptographic authenticity proof.
- Request facts
- Prompt, model, ratio, workflow, source referencesPreserve the values actually submitted, with secrets and unnecessary personal data excluded.
- Execution facts
- Provider, generation ID, request and completion timesLabel whether each value came from Studio, the provider, or the client clock.
- Output facts
- Asset reference, media type, optional digestA locally calculated digest is an optional checksum, not a Studio-returned field or proof of who generated the asset.
Build the manifest at the point where evidence exists
Before the call, create a local record with a manifest version, the MCP server identity you configured, the tool name, sanitized arguments, and a client timestamp. After the start result, append the server-returned generation identifier, model, provider, normalized settings, and status without overwriting the original request. After retrieval, append the completion time as reported or observed, the authenticated asset reference, media type, and a digest calculated from the downloaded file.
Studio’s privacy policy says signed download links expire quickly and require account authorization to mint. Preserve a stable local asset reference after an authorized download rather than treating the signed URL as the asset’s permanent identity. Keep uncertainty visible: `requestedModel`, `returnedModel`, and `providerDisplayedBeforeRun` can remain separate fields. If only the requested model is known, say so. Record `clientRequestedAt` separately from `providerCompletedAt`, and omit the provider field when no provider timestamp was supplied.
- Before start
- Manifest version plus sanitized requestDo not put API keys, bearer tokens, signed URLs, or unnecessary personal data in the ledger.
- After start
- Original tool result plus generation handleKeep the unmodified structured result when available so later normalization remains auditable.
- After download
- Stable local path plus digestTreat a short-lived delivery URL as transport, not as the permanent identity of the media.
Do not upgrade a database row into a cryptographic guarantee
An account-history row, JSON manifest, or file hash can improve traceability, yet none automatically proves authorship or prevents alteration. A hash can show whether the bytes still match a captured digest. It cannot establish who made the original claim, whether the recorded prompt was complete, or whether a model label was truthful. Likewise, MCP `structuredContent` is server-produced data; schema validation checks shape, not the truth of every field.
C2PA Content Credentials use a different trust model. Version 2.4 describes assertions bound into a manifest with a digitally signed claim and content bindings, enabling tamper-evidence and validation against signer credentials. The specification also cautions that validated provenance statements are trust signals rather than value judgments about whether content is good, bad, or substantively true. Unless an actual asset carries a C2PA manifest that has been validated, describe the operational ledger as recorded provenance, not as cryptographically verified provenance.
- Plain manifest
- Structured operational traceHelpful for review and incident reconstruction, but editable unless protected by another control.
- File digest
- Byte-integrity checkDetects a changed file relative to the captured digest; does not identify the creator.
- C2PA Content Credential
- Signed assertions bound to contentRequires a claim generator, signer credential, content binding, and validation process.
Evidence boundary and next checks
The supported product conclusion is limited: Studio documents prompt, source media, model, aspect ratio, workflow, generated media, account-history retention, and a disclosed fal processing path shared by web, API, MCP, and CLI. The cited public pages do not define a complete history-export schema or promise cryptographic provenance. This draft therefore recommends a local, origin-labelled ledger and does not claim that Studio emits hashes, seeds, immutable timestamps, model revisions, or C2PA Content Credentials.
The required recent-community pass was used only to assess whether community evidence could support this page. It returned 92 items with zero relevance-qualified records for MCP-generated media provenance recording, so no community post, comment, engagement number, consensus statement, or anecdote is used as product evidence. Per-source outcomes, errors, counts, exact invocation details, and artifact hashes remain methodology records in the evidence brief and ignored raw directory rather than publication claims.
No production generation was submitted, no authenticated account history was inspected, and no MCP result was captured from a live Studio account. The research did not test deletion, export, signed-link expiry, provider dashboards, byte digests, embedded metadata, or C2PA validation on a generated asset. Before editorial review, compare a real sanitized tool result with the corresponding account-history entry and downloaded file, then document every field that is present, absent, transformed, or client-observed.