Sume MCP assets_create vs upload: registered URLs are unverified
On Sume MCP, assets_create registers unverified metadata for a remote URL. For bytes you own, use assets_upload_url, a client PUT, then assets_complete.

On Sume's hosted MCP, assets_create registers metadata only. A remote URL asset it registers has status: registered and should be treated as unverified, not generation-ready first-party media. For bytes you own, call assets_upload_url, PUT the file from the client, then call assets_complete.
Three ways to get media in
The tool docs list assets_create, assets_upload_url and assets_complete as write tools that need an idempotency_key. Hosted MCP cannot read files from your laptop, so the upload flow has three steps: create an upload URL, PUT the bytes from the client, then complete. Social video links are a different route: media-imports_create fetches and mirrors them into Sume storage.
| Source | Tool path | State |
|---|---|---|
| Bytes you hold | assets_upload_url, PUT, assets_complete | uploaded first-party asset |
| A remote URL you trust | assets_create | registered, unverified metadata |
| A TikTok or Instagram URL | media-imports_create, then jobs_wait | mirrored into Sume storage |
| A merchant image behind hotlink protection | products_mirror_image with source_url | mirrored |
The redaction wrinkle
On the remote server the signed upload.url is masked, so a remote agent cannot do the PUT itself. The next steps say not to retry the PUT with [redacted], and name the sanctioned alternatives: mirror an external image with the dedicated tool, or use the REST bridge for sandbox-local bytes. See the upload URL post for the public HTTPS route.
A routing helper
Decide the path from what you hold.
def path_for(source: str) -> str:
if source == 'local_bytes':
return 'assets_upload_url -> PUT -> assets_complete'
if source == 'social_url':
return 'media-imports_create -> jobs_wait'
if source == 'remote_url':
return 'assets_create (unverified)'
raise ValueError(f'unknown source {source!r}')
print(path_for('social_url'))Limits
registered does not mean a URL is bad; it means Sume has not verified it. If a generation needs the media to be stable, upload it. Do not echo raw source URLs or signed URLs in user-facing reports.
Why the distinction exists
A registered remote URL is a pointer. Sume has not fetched the bytes, checked the type or stored a copy, and the remote host can change or remove the file. A generation that depends on it can fail late. An uploaded asset has been written to Sume storage and completed, so later steps can rely on it. The next steps on the tool say exactly this.
Checklist before you ship
- Use create upload URL, then client PUT, then assets_complete for bytes you own.
- Use assets_create only to register metadata you accept as unverified.
- Use media-imports_create to pull a social video URL into Sume storage.
- Never invent a media_id; take ids from tool results.
Sources
Related posts
More in Developers
- Sume MCP conflicting_model: top-level model vs payload.model
avatar-image-to-video_create lifts payload.model to the top level. If the two differ you get conflicting_model plus supported_models. Send one, or match them.
- Sume MCP dry run: next_step is only dry_run false, merge your payload
A paid Sume MCP dry run returns would_submit false and next_step arguments of just dry_run false. Re-send your original idempotency_key and payload with it.
- Sume MCP generation_admission_rejected: read the preview first
generation_admission_rejected means the admission preview would not accept the request. Read the preview, then change the request or wait before retrying.
- Sume job_failed_terminal: retryable true means reuse the same key
On job_failed_terminal never resubmit the identical payload. If error.retryable is true, re-issue the create with the same idempotency_key; else fix the input.
Written by Sume