← Wondershare Media.ioCONTENT HISTORY

Update to Wondershare Media.io

Snapshot Oct 31, 2026 · 01:22 UTC · version 1.0.0

Collection source: downloaded plugin package.

WHAT CHANGED

First saved snapshot

No earlier snapshot is available to establish a change.

Save Wondershare Media.io and check future changes in Following.

Up to 10 plugins free · no card required.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Generate images and videos through the connected Media.io MCP server using\ntext_to_image, image_to_image, text_to_video, image_to_video,\nreference_to_video, motion_control, or image_audio_to_video. Select a model\nfrom the static release catalog and follow its model-specific schema.\nGeneration normally consumes existing account credits; submit quietly when\nthe user requests generation. Use estimate_credits only when the user asks\nabout cost or requests an estimate, never as a routine prerequisite.\nSource media must be file IDs from the user's Media.io drive. Upload local\nfiles only when the host can read bytes, compute SHA-1 and perform HTTP PUT.\nWait with get_generation, then show finished results once with\nget_generation_card. View past or recent tasks with list_generations_card.\nNo local CLI or installation is needed.\n",
  "included_files": [
    {
      "relative_path": "references/credit-approval.md",
      "size_in_bytes": 2115
    },
    {
      "relative_path": "references/media-inputs.md",
      "size_in_bytes": 2455
    },
    {
      "relative_path": "references/model-catalog.md",
      "size_in_bytes": 10271
    },
    {
      "relative_path": "references/model-parameters.md",
      "size_in_bytes": 75884
    },
    {
      "relative_path": "references/model-release.json",
      "size_in_bytes": 256
    },
    {
      "relative_path": "references/model-selection.md",
      "size_in_bytes": 9768
    },
    {
      "relative_path": "references/prompt-engineering.md",
      "size_in_bytes": 2740
    },
    {
      "relative_path": "references/tool-contract.md",
      "size_in_bytes": 5485
    },
    {
      "relative_path": "references/troubleshooting.md",
      "size_in_bytes": 1641
    }
  ],
  "name": "mediaio-aigc",
  "skill_md_contents": "---\nname: mediaio-aigc\nmetadata:\n  version: \"1.0.0\"\ndescription: |\n  Generate images and videos through the connected Media.io MCP server using\n  text_to_image, image_to_image, text_to_video, image_to_video,\n  reference_to_video, motion_control, or image_audio_to_video. Select a model\n  from the static release catalog and follow its model-specific schema.\n  Generation normally consumes existing account credits; submit quietly when\n  the user requests generation. Use estimate_credits only when the user asks\n  about cost or requests an estimate, never as a routine prerequisite.\n  Source media must be file IDs from the user's Media.io drive. Upload local\n  files only when the host can read bytes, compute SHA-1 and perform HTTP PUT.\n  Wait with get_generation, then show finished results once with\n  get_generation_card. View past or recent tasks with list_generations_card.\n  No local CLI or installation is needed.\n---\n\n# Media.io generation\n\nUse the connected tools and their static input schemas as the contract. If unavailable, explain that the Media.io connection is missing. Do not replace the MCP operation with another plugin, a local CLI or an unexposed upstream API.\n\n## Operation selection\n\n| User intent | Tool | Sources in `request.inputs` |\n| --- | --- | --- |\n| Image from a description | `text_to_image` | None |\n| Edit or reinterpret source images | `image_to_image` | Model-specific image file fields |\n| Video from a description | `text_to_video` | None |\n| Animate an image, or declared start/end frames | `image_to_video` | Starting image; ending image when required |\n| Video guided by declared references | `reference_to_video` | Model-specific images, video, audio or document references |\n| Animate an image using a motion video | `motion_control` | Reference image and motion video |\n| Music video from an image and audio | `image_audio_to_video` | Image and audio |\n\nRead [model-catalog.md](references/model-catalog.md) for this release's callable models and lifecycle status. Match the user's selected model to an exact ID within the requested action. Repeated display names are not unique IDs: ask for clarification when the available variants materially differ. Never infer a workflow code or transfer options from another model.\n\nWhen the user does not specify a model, read [model-selection.md](references/model-selection.md) for generated defaults, scenario rules and aliases. Follow only actions exposed by the connected server. Deprecated models are not defaults or recommendations; replacement candidates do not authorize substitution. Never switch away from an explicitly selected model without the user's request.\n\nVideo editing or extension as a separate operation, persistent character creation, training and publishing are outside this release. A temporarily unavailable model does not authorize discovery or bypassing the declared contract. New upstream models do not become callable automatically.\n\n## Normal flow\n\n1. Select the operation and exact model. Read that model's section in the generated [model parameters](references/model-parameters.md), including UI label mappings, defaults and coupled option branches. Put business fields inside `request`: `model`, the declared `prompt`, model-specific `inputs`, and strict `options`. Extract explicit settings from the user's message, supplied prompt or screenshot, and referenced earlier request into the model's declared fields. Match each setting to its declared field and mapped value; user settings take precedence over defaults. For sizing, also follow [Output size](references/prompt-engineering.md#output-size). Resolve unsupported or conflicting requirements before creation. One call creates one task, not a Web UI batch.\n2. Resolve source media with `list_assets`. For an earlier task output, use its `asset_id` to look up the corresponding `file_id`. Never invent an ID, use another account's media, or pass a URL/path as a file ID.\n3. Submit with the corresponding generation tool and a stable `client_request_id`, omitting `approved_credit` by default. The user's generation request authorizes the normal use of their existing credits. Do not add an estimate, account card, cost announcement or credit-confirmation turn by default. The server skips pre-submission estimation on this path; batch size or an inferred interest in saving credits does not change it.\n4. Read `task_id`, call `get_generation`, and continue after `poll_after_ms` until all tasks are terminal. A call may wait 25 seconds. Do not resubmit a running task. For requested sizing, compare available output `width` and `height` with the selected pixel size. Report a mismatch or unavailable dimensions without automatically regenerating.\n5. Call `get_generation_card` once after completion. The card is the result presentation; follow it with at most a short sentence.\n\nFor multiple user-requested tasks, use a different request identifier per task. Retries must preserve the identifier and all business inputs. Never create extra tasks, change models or regenerate after an error without a new user request.\n\n## History queries\n\nWhen the user asks to view past or recent generations, call `list_generations_card` directly. Use `page: 1, page_size: 10` unless the user specifies a count; each page supports at most 100 tasks. Preserve any requested task ID or status filters. For a requested next page, keep those filters and the page size and increment `page`.\n\nThe history card shows the current snapshot, including running and failed tasks. After it renders, say at most one short sentence. If the host cannot render cards, summarize the returned `generations` and `total` as a short list. Do not wait for every history task to finish or add `get_generation_card` per task merely to show history.\n\nUse `list_generations` for background inspection, including matching an uncertain submission after `RESULT_UNKNOWN`. Use `get_generation` to follow known task IDs; the normal generation flow still ends with `get_generation_card`. A history query never authorizes creating, retrying or regenerating tasks. If `list_generations_card` is unavailable, explain that the connected server needs the history-card tool; do not use an unexposed API.\n\n## Cost questions\n\n`estimate_credits` takes `{ \"request\": { \"operation\": \"text_to_image\", \"generation\": { \"model\": \"text2image_gpt_image_2\", \"prompt\": \"A red paper crane\" } } }`. Its `request.generation` is exactly the corresponding tool’s business `request`, without `client_request_id` or `approved_credit`. It does not create a task. A request to estimate only must remain read-only. When the user subsequently asks to generate, submit normally.\n\nOnly use optional `approved_credit` when the user explicitly wants a known estimated amount guarded. Supplying it makes the server calculate and compare the amount before submission. On `CREDIT_CHANGED`, do not silently replace the guard and retry. The guard is not an atomic upstream quote.\n\nA creation receipt may contain `frozen_credit`, the amount frozen by the upstream create request. An absent value means unknown, not zero or free; do not run an estimate to fill it in. Optional `estimated_credit` is only a pre-submission estimate from explicit amount protection or an older task replay. Neither field is a final settlement record. Do not claim refunds or that a failed terminal task necessarily consumed no credits.\n\nOn `CREDIT_INSUFFICIENT` or `PLAN_REQUIRED`, explain neutrally that the task is unavailable with the current balance or entitlements, then stop. Do not suggest purchasing, topping up, upgrading or subscribing; do not provide a transaction link, upgrade card or fallback that spends credits automatically. Existing paid users may use their included entitlements normally.\n\n## Source transfer and results\n\nUse existing Media.io drive files whenever possible. Local upload is conditional on actual host capabilities: read the bytes, calculate their size and SHA-1 digests, call `create_upload`, perform the exact returned PUT, then `complete_upload`. A completed rapid upload needs no PUT or completion call. A host attachment reference alone does not prove those capabilities. See [media-inputs.md](references/media-inputs.md).\n\nPrefer the native result card. Use signed result URLs verbatim only through delivery capabilities supported by the host; never rewrite their query strings or download media to bypass display restrictions. If saving a requested original is permitted, link the returned local file with an absolute path. Refresh an expired result by querying the task again; never repair a signature.\n\n## Errors and privacy\n\nAct on structured error codes. `RESULT_UNKNOWN` means stop submitting: inspect `list_generations` pages and task timestamps, without inventing a time-filter parameter, and explain uncertainty if no reliable match exists. `AUTH_*` requires authorization or resource access resolution. `INVALID_PARAMETER` requires following the current tool schema. `CAPABILITY_NOT_FOUND` may indicate availability or contract drift; do not discover new schemas or models.\n\nKeep account, asset and task data private to the authorized user. Do not show tokens, unrelated prompts or internal diagnostics. Use `get_account_card` only when the user asks to view their connected account, existing balance or membership. The card displays the current account's nickname and email from widget-only metadata, plus existing membership and credits, without buttons or navigation links; do not repeat its identity or rendered data in prose. See [tool-contract.md](references/tool-contract.md), [credit-approval.md](references/credit-approval.md) and [troubleshooting.md](references/troubleshooting.md).\n"
}

SHA-256 of public snapshot: 4c5ac07ff714ed5b8d7c85266e86f2910d5126b445a2170277a9bab5cd64b9e2