agent-media

set_series_cover

Destructive

Costs no credits, generates nothing. Set the cover (poster) of your series: the picture the public series page, the Library and Studio show (cover_url in get_series, list_series and get_series_overview). image: the https URL of a picture in this account, a generate_image output, an upload_image URL or an upload panel image (open_upload_panel, get_uploads) (PNG, JPEG or WebP, at least 200 pixels a side, up to 15 MB; vertical 2:3 fits best). The picture is copied into the series' own storage. Leave image out (or pass null) to go back to the default cover, the lead's portrait: that returns cleared true, cover_set false and the default cover_url. Returns cover_set, cover_url, warnings and say (post it as is); a refused picture returns cover_set false with reason (image_not_allowed, not_an_image, image_too_small, image_too_large, image_missing, download_failed, storage_failed) and say.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "series_id": "<series_id>"
    },
    "name": "set_series_cover"
  }
}

Input Schema

Name	Required	Description	Default
`image`	No
`series_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true and the description explains exactly what that means in practice: the picture is copied into the series' own storage and any prior cover is replaced or reset to the lead's portrait. It adds cost/credit behavior, the full set of constraint failures with reason codes, and the shape of the response (cover_set, cover_url, warnings, say), all beyond what the annotations carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the two things an agent most needs (no credits, generates nothing) before the mechanics. Dense but every clause carries information; the long nested parenthetical of formats/limits and the reason-code list make it a heavy single block that would read better split into bullet-like clauses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description covers return fields, the cleared-cover case, and each failure reason, and it specifies the clearing and storage semantics of a destructive mutation. There is nothing an agent needs in order to call this correctly that is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description bears the full load, and it does for `image`: accepted URL origins, PNG/JPEG/WebP, ≥200 px per side, ≤15 MB, 2:3 preference, and the null/omitted semantics. `series_id` is left undefined, which is the only real gap for a two-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb+resource ("Set the cover (poster) of your series") plus where the result surfaces ("cover_url in get_series, list_series and get_series_overview"). "Costs no credits, generates nothing" implicitly if not explicitly separates it from the generative sibling make_series_cover, but no sibling is named, so the routing is left partly to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the operation's context and gives an explicit clearing rule ("Leave image out (or pass null) to go back to the default cover, the lead's portrait") with the resulting flags. It also points at valid image sources (generate_image output, upload_image URL, open_upload_panel, get_uploads), but never explicitly tells the agent when to pick this over make_series_cover.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All agent-media tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?