Compose printable VHS, DVD, cassette, CD and vinyl packaging from any movie, show, or album.
Scored across 16 tools
Most tools target clearly different resources or actions, and paired tools like export_design/get_export, list_formats/describe_format, and list_uploads/upload_image/delete_upload are well-separated. However, compose_design and save_design both create a design with the same fields, differing mainly in whether the result is a browser URL or a saved dashboard entry, which could cause occasional misselection.
All tools follow a consistent snake_case verb_noun pattern (e.g., compose_design, list_formats, get_content, delete_upload). There are no mixed conventions or incompatible verb styles.
16 tools is slightly above the typical 3–15 range but remains reasonable for a feature-rich design app with design lifecycle, export jobs, uploads, format metadata, and content lookup. No tool appears redundant, though the count is on the heavy side.
The surface covers the core workflow well: discovery (formats, decals, content), design creation/saving/retrieval/listing/deletion, upload management, export/preview polling, and account checks. One minor gap is the lack of an explicit update_design tool for an existing saved design, but agents can work around this by composing or saving a new variant.
Build a label design and return a URL the user opens to finish it. Designing and previewing are free; exporting a print-ready file requires a membership, so present the URL as a starting point the user completes in their browser. Fields listed in the response as "unsupported" were NOT applied — tell the user rather than reporting them as done. The user's own artwork goes in through images (upload it first with upload_image; needs an API key): images.background covers the whole sheet, images.panels.<key> one panel each (keys from describe_format), images.logo a custom studio logo. decals places catalog stickers / shapes / retro marks (ids from list_decals) or the user's uploads anywhere on the sheet, texts adds free text blocks, style.productionLogos picks the studio marks (style.productionLogoColorize: 'off' keeps their own colours), and layout.hide: ["poster"] clears the cover art — enough to rebuild a specific vintage cover. Without a key, compose from format + content and tell the user to drag images in after opening the URL.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Overrides for the fetched metadata (video formats only — on audio formats these come back as unsupported). Omit a field to keep the provider value. | |
| style | No | ||
| texts | No | Free text blocks placed on the label (the designer's Text tab). x/y are the block's center in percent of the sheet; width is the percent of the sheet width the block spans (text wraps); size is the font size as percent of the sheet height. | |
| decals | No | Stickers, graphics, shapes and the user's own images placed on the label. Each entry names a catalog decal by id (list_decals) OR an upload by ref (upload_image; needs the API key). x/y are percent of the sheet (center-anchored; see describe_format → placement for the coordinate space and the size units). Size with `width` (percent of the sheet width) where describe_format accepts it, else `scale`. | |
| format | Yes | Which packaging format | |
| images | No | The user's own artwork by upload ref (from upload_image). Needs the API key that owns the uploads. Single-surface formats only (describe_format → singleSurface). Each value is a ref string or { ref, fit, opacity }. | |
| layout | No | ||
| content | No | What the design is of. Provide a query, or an id from search_content. Video formats take movie/tv; audio formats (cassette, jcard, cd*, vinyl*, minidisc*) take album. For audio, the album alone builds the complete design — cover art, tracklist sides, QR code — and style.font / labelColor / background restyle it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that designing/previewing is free while export is gated, that images require an API key, that unknown panel keys come back as 'unsupported', and instructs the agent to report unsupported fields rather than claim success. That is exactly the operational context annotations (readOnly/openWorld) cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the URL/export caveat are front-loaded, and nearly every clause carries a concrete instruction rather than filler. It is a single dense paragraph though, with several long appositive lists, so it is heavier than it needs to be for scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter nested tool with no output schema, the description covers the return value (URL), the gate on export, the API-key dependency, and the unsupported-field contract, plus per-parameter routing. It does not describe anything else the response contains (e.g. the unsupported list shape), which is a minor gap given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage the schema does much of the work, but the description adds real cross-references: which image slot is which (images.background vs panels.<key> vs logo), where decal/text/style.productionLogos and layout.hide fit, and the practical pattern for rebuilding a specific cover. It leaves a few areas (layout.spine2, style.finish, text overrides) to the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource ('Build a label design') plus the distinctive output (a URL the user opens to finish it), which separates it from save_design and export_design by implication. However, it never names those siblings, so the distinction must be inferred from the free-vs-membership note rather than stated outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Routes the agent explicitly: upload artwork first with upload_image, get decal ids from list_decals, panel keys from describe_format, and states the fallback path when no API key is available (compose from format + content, tell the user to drag images in later). It also names the alternative outcome (export needs a membership) so the agent knows this tool stops at the URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one of the user's saved designs (and the image copies it owns). Irreversible — confirm with the user first. Needs an API key with design:write.
| Name | Required | Description | Default |
|---|---|---|---|
| designId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the safety profile is known, yet the description adds material context beyond them: the operation is irreversible, it also destroys owned image copies, and it requires a specific API-key scope. Only the response behavior is unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight clauses, front-loaded with the action, then the irreversibility warning, then the auth prerequisite. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with no output schema, the description covers what is deleted, the cascade side effect, irreversibility, and the required credential — everything an agent needs before calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, 'designId', with 0% schema description coverage, and the description adds no meaning about its format or source. The name is largely self-explanatory, but the description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Delete') and resource ('saved designs'), and even clarifies the cascade scope ('the image copies it owns'). This distinguishes it from the sibling delete_upload, which targets uploads rather than saved designs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear prerequisite ('Needs an API key with design:write') and a usage condition ('confirm with the user first'). It does not name an alternative tool, but for a terminal destructive action the gating advice is the relevant guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove one image from the user's Uploads library by id (from upload_image or list_uploads). Needs an API key with design:write. Saved designs keep their own copies, so this never breaks a design; it only frees a library slot. Prefer deleting images this session uploaded over ones the user added themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| uploadId | Yes | The id (or upload:<id> ref) to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it discloses the required scope (API key with design:write), the blast radius ('Saved designs keep their own copies, so this never breaks a design; it only frees a library slot'), and a policy preference. This tells the agent exactly what is destroyed and what is not - a mutation tool worth of trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the action and the id source before the caveats and preference. Every sentence carries information; slightly dense but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and destructive/readOnly hints already supplied, the remaining burden is auth and side effects - both covered. Only the result of a delete (success/not-found behavior) is unstated, a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds provenance for the id ('from upload_image or list_uploads') and notes the upload:<id> ref form is acceptable, which is not spelled out as clearly in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: 'Remove one image from the user's Uploads library by id'. It also names where ids come from (upload_image or list_uploads), which clearly separates it from delete_design, which targets a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a real operating rule: 'Prefer deleting images this session uploaded over ones the user added themselves', and points to the tools that produce valid ids. It does not explicitly contrast with delete_design, but the context is clear enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One format in detail: the printed sheet in px and inches at export DPI, every panel (front, spine, back, flaps…) as a rectangle with its pixel size, and which intent sections the format accepts. Call this BEFORE generating artwork for a format so each image is made at the right size and aspect.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | A slug from list_formats |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real value by disclosing what the call returns — export-DPI dimensions, panel geometry, and supported intents — which is behavior an agent can't infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the ordering is correct: the payload description comes first, then the actionable 'call this BEFORE...' instruction. Everything stated earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return-value burden — and it does, describing the sheet, panels, and intent sections. Combined with read-only annotations and a fully documented single parameter, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single enum'd parameter is documented in the schema ('A slug from list_formats'). The description adds no further constraint or format detail about the parameter itself, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — describing ONE format in detail — and enumerates exactly what that detail contains (sheet dimensions in px and inches at export DPI, per-panel rectangles, accepted intent sections). This clearly separates it from the sibling list_formats, which enumerates all formats rather than describing one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes when to call it: 'Call this BEFORE generating artwork for a format so each image is made at the right size and aspect.' That is a clear sequencing rule tied to a concrete downstream task. It stops short of naming alternatives (e.g., list_formats for slug discovery), so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a saved design. Queues a job — a headless renderer produces the file in ~15–60 s — and returns a jobId; poll get_export. output 'preview' (every plan) is a downscaled image of the whole sheet that get_export returns INLINE so you can look at it: render one after every save, check the layout, cover art, text sizes and colours against what the user asked for, fix the intent and save again before exporting. 'png' is the Original full-resolution print PNG (600 DPI) and 'pdf' its design-size PDF — members only, and only once the preview looks right. Needs an API key with the export scope.
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | 'preview' to see the design, 'png' (default) or 'pdf' for the print file | |
| designId | Yes | From save_design or list_designs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only tell the agent this is not read-only and not destructive. The description adds the behavior that actually matters: the call is asynchronous, takes ~15-60 s, returns a jobId that must be polled via get_export, that 'preview' is returned inline (a non-obvious response shape), and that an API key with the export scope is required. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and async behavior, and every sentence carries information. It is dense and a couple of clauses run long ('render one after every save, check the layout, cover art, text sizes and colours...'), but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by explaining the return value (jobId plus inline preview image) and the polling follow-up. With a required designId sourced from save_design/list_designs and only two parameters, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description genuinely extends the enum semantics: 'preview' is a downscaled whole-sheet image returned inline, 'png' is 600 DPI full-resolution, 'pdf' is design-size, and both print outputs are members-only. That is real added meaning beyond the schema's one-line enum labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Render a saved design') and immediately clarifies it is asynchronous ('Queues a job ... returns a jobId'), which separates it cleanly from get_export. The sibling set contains both get_export and get_design, and this description makes clear which one is the trigger versus the poller.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit workflow: render a 'preview' after every save, verify layout/cover art/text/colours, fix intent and save again, then export 'png' or 'pdf' once the preview looks right. It also states the gating conditions for the full-resolution outputs ('members only, and only once the preview looks right'). This is unusually complete when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who the API key belongs to: membership tier, today's remaining agent quotas, saved-design and upload-library counts. Needs an API key (Authorization: Bearer tc_live_…, created at https://vhs.texs.org/en/dashboard?tab=settings). Call it once to confirm the key works before uploading or saving.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely new context: an auth requirement with header format and a key-creation URL, plus the recommendation to use it as a key-validity probe. It does not describe rate limits or response shape, but the auth and pre-flight-use details are meaningful additions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what the tool returns before the auth and usage details. The dashboard URL is slightly bulky but earns its place as the key-provisioning pointer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description compensates by enumerating the payload (tier, quotas, design and upload counts), and it fully covers the auth prerequisite. An agent has everything needed to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a parameterless tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Who the API key belongs to') and enumerates the returned data: membership tier, remaining quotas, saved-design and upload-library counts. No sibling tool does anything comparable, so it is trivially distinguishable from the design/upload/content tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage condition: 'Call it once to confirm the key works before uploading or saving,' which tells the agent when to reach for it. It does not name an alternative or an explicit when-not-to-use case, so it falls short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A movie or TV title's own artwork: every TMDB poster, logo (the wordmark / title art) and backdrop (stills) as a decal id with pixel size and preview URLs, plus title, year, tagline and overview. Place one with decals[].id in the same intent as the content (e.g. the real wordmark under the cover art, a still on the back) — sized by width like any decal. Ids come from search_content.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | TMDB id from search_content | |
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (decal ids, pixel dimensions, preview URLs, plus metadata fields) even though no output schema exists, and by explaining how ids are consumed downstream.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the return contents, then a single usage sentence — every clause earns its place and nothing is redundant. It is dense in the first sentence but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so well, listing the artwork kinds and accompanying metadata. For a two-parameter read tool with annotations covering safety, this is essentially complete; only a note on result volume/pagination is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: the 'id' param is documented as 'TMDB id from search_content', which the description reinforces, while 'type' relies solely on its movie/tv enum. The description's 'A movie or TV title's own artwork' implicitly frames the type parameter, adding modest meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource (fetch a movie/TV title's artwork) and enumerates exactly what comes back: posters, wordmark logos, backdrops as decal ids with pixel size, preview URLs, plus title/year/tagline/overview. It is clearly distinguishable from the sibling search_content, which the description explicitly positions as the id source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the prerequisite and source ('Ids come from search_content') and tells the agent what to do with the result ('Place one with decals[].id in the same intent as the content... sized by width like any decal'). There is no explicit when-not-to-use exclusion, but the workflow context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One saved design by id: name, format, link and its raw design params. Needs an API key with read.
| Name | Required | Description | Default |
|---|---|---|---|
| designId | Yes | From list_designs or save_design |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful operational constraint beyond that: it requires an API key with read scope, and it discloses the shape of the returned payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence covering resource, identifier, return fields, and auth requirement with no filler. The auth requirement sits at the end rather than being front-loaded, which is a minor structural quibble.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with no output schema, the description supplies exactly what is needed: how to identify the record and what comes back, including the raw design params field that would otherwise be invisible. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 100%, so the schema already documents that designId comes from list_designs or save_design. The description's 'by id' adds no format, validation, or sourcing detail beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific retrieval action on a named resource ('One saved design by id') and enumerates the returned fields (name, format, link, raw design params). It implicitly separates itself from list_designs by fetching one record, though it never names the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the agent infers it should supply an id sourced from list_designs or save_design (that routing hint lives in the schema, not the description). No explicit when-to-use-vs-alternatives guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of an export job from export_design. When status is done, file.url is a download link valid for an hour; a preview job also returns the image itself. Files are kept for a day, then the job reads expired.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/non-destructive profile, and the description goes further with concrete lifecycle facts: file.url is valid one hour, files are kept one day, then the job reports expired, and preview jobs also return the image itself. That is exactly the kind of TTL/state behavior an agent cannot get from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool returns and then the time-sensitive caveats; nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-shape burden and does it well (status, file.url, preview image), but it leaves the jobId origin and the full set of status values implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single jobId parameter, and the description only implies it comes from export_design; it adds the useful provenance link but no format or validity details, so it partially compensates for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (an export job) and its status, and ties itself to the sibling export_design that creates it, so an agent can tell it apart from the other design/upload tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: referencing export_design hints that this is the follow-up poll, but the description never says 'call this with the jobId returned by export_design' or when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The decal catalog: every sticker, graphic, shape and retro distributor mark the designer offers (a title's own posters / logos / stills come from get_content instead), grouped by category, each with its id (what decals[].id takes), natural pixel size and preview URLs — plus the Classic Logo ids style.productionLogos takes. Call it before placing decals; ids are exact strings, never guessed. Pass a category id to get one category, or a query to search names.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Case-insensitive match on decal id / name | |
| category | No | One category id (e.g. "priceTags", "oldDistributors", "shapes") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful integration context — that ids must not be guessed and that the returned ids feed decals[].id and style.productionLogos — but says nothing about pagination, catalog size, or result ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense paragraph, front-loaded with what the catalog contains, then constraints, then parameter modes. Every clause carries information, though the long parenthetical aside about get_content interrupts the flow mid-sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly enumerates the return shape (grouping by category, id, natural pixel size, preview URLs) and names the downstream consumers of those ids. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents query as a case-insensitive match on id/name and category as a single category id with examples. The description restates these semantics ('one category', 'search names') without adding format, default, or combination rules, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('the decal catalog') and enumerates its contents precisely (stickers, graphics, shapes, distributor marks). It explicitly excludes a sibling's territory — 'a title's own posters / logos / stills come from get_content instead' — so an agent can distinguish it from get_content and search_content without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a direct imperative ('Call it before placing decals'), a hard constraint ('ids are exact strings, never guessed'), and the routing condition for the alternative (get_content for title-owned artwork). It also explains both usage modes: category id for one category, query for name search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's saved designs, newest first, with their links. total is how many designs match (the user may have hundreds); page on with offset = nextOffset until it is null. Filter by format (a list_formats slug, e.g. 'slipcover', 'vhslabels') or query (matches the design name or the movie/album title). Needs an API key with read.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 25 | |
| query | No | Case-insensitive match on the design name or content title | |
| format | No | Only designs of this format slug (list_formats) | |
| offset | No | Skip this many (newest first). Use nextOffset from the previous page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavioral context: sort order (newest first), the meaning of `total` as a full match count ('the user may have hundreds'), the pagination termination condition, and the read-scoped API key requirement. It stops short of rate limits or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the resource and ordering, then pagination, then filtering, then auth. Every clause carries information that maps to a parameter or a caller decision; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully compensates by explaining `total` and `nextOffset`, the two return fields an agent must act on. It only partially covers the returned design objects ('with their links'), leaving the rest of the design payload shape implicit, which is the one gap for a list tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3. The description goes beyond the schema by giving concrete example format slugs ('slipcover', 'vhslabels') and clarifying that `query` matches the movie/album title, not just the design name. It adds useful disambiguation the schema's terse one-liners lack.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific resource and scope: 'The user's saved designs, newest first, with their links.' That verb-implicit listing is clearly distinguishable from siblings like list_uploads, list_decals, and list_formats, which cover different resource types. An agent can route to this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete when-to-use guidance for filtering ('Filter by `format` ... or `query`') and a full pagination recipe ('page on with `offset` = `nextOffset` until it is null'), plus the auth prerequisite ('Needs an API key with read'). It does not name an alternative tool (e.g. get_design for a single design), which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the packaging formats that can be composed, with their printed dimensions. Call this first if you are unsure which format the user wants.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description usefully adds that the output includes printed dimensions and that this is the intended entry point in the workflow. It does not add auth or rate-limit detail, but none is needed for a zero-argument read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with what the tool returns and followed by the routing advice. No filler or restated title text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no parameters, so the description must carry the return-value burden, which it does only partially ('printed dimensions'). The shape of each format entry, and pagination/ordering, is left unspecified, though for a simple enumeration tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ('List') with a specific resource ('packaging formats') and even states what is returned ('their printed dimensions'). It implicitly separates itself from the describe_format sibling by telling the agent to call this one first when the format is unknown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit triggering condition: 'Call this first if you are unsure which format the user wants.' That is clear when-to-use guidance, though it never names describe_format or explain when to skip this and go straight to that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's Uploads library, newest first: id, upload: ref, name, pixel size, bytes and an hour-long preview url. Needs an API key with read. Use it to reuse an image already uploaded (identical bytes dedupe anyway) or to pick what to delete_upload when upload_image answers LIBRARY_IMAGE_LIMIT.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the bar is lower, yet the description still adds real context: it requires an API key with read scope, preview URLs expire after an hour, and identical-byte uploads dedupe. It stops short of describing pagination behavior beyond the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, zero filler. The resource, sort order and returned fields are front-loaded before the usage and auth notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the returned fields itself, and it also covers auth requirements and the error-driven workflow (LIBRARY_IMAGE_LIMIT -> delete_upload). Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single limit parameter is documented with default/min/max, so baseline is 3. The description adds ordering semantics ('newest first'), which tells the agent what the limit actually slices, a modest but genuine addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the user's Uploads library') and immediately enumerates the returned fields and sort order ('newest first: id, upload:<id> ref, name, pixel size, bytes and an hour-long preview url'). An agent can distinguish this from list_designs/list_decals/search_content without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions and names the related tools: reuse an already-uploaded image (noting identical bytes dedupe anyway) or pick a target for delete_upload when upload_image returns LIBRARY_IMAGE_LIMIT. The alternative-tool routing is concrete rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a design straight to the user's dashboard and return its link. Takes the SAME fields as compose_design plus a name; needs an API key with design:write. Use it when the user wants the design kept on their account without opening a link first. Images are copied into the design (safe to delete from the library afterwards). The preview thumbnail and the frozen content snapshot are captured the first time the owner opens and saves it in the browser — say so.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Design name shown on the dashboard (max 120 chars) | |
| text | No | Overrides for the fetched metadata (video formats only — on audio formats these come back as unsupported). Omit a field to keep the provider value. | |
| style | No | ||
| texts | No | Free text blocks placed on the label (the designer's Text tab). x/y are the block's center in percent of the sheet; width is the percent of the sheet width the block spans (text wraps); size is the font size as percent of the sheet height. | |
| decals | No | Stickers, graphics, shapes and the user's own images placed on the label. Each entry names a catalog decal by id (list_decals) OR an upload by ref (upload_image; needs the API key). x/y are percent of the sheet (center-anchored; see describe_format → placement for the coordinate space and the size units). Size with `width` (percent of the sheet width) where describe_format accepts it, else `scale`. | |
| format | Yes | Which packaging format | |
| images | No | The user's own artwork by upload ref (from upload_image). Needs the API key that owns the uploads. Single-surface formats only (describe_format → singleSurface). Each value is a ref string or { ref, fit, opacity }. | |
| layout | No | ||
| content | No | What the design is of. Provide a query, or an id from search_content. Video formats take movie/tv; audio formats (cassette, jcard, cd*, vinyl*, minidisc*) take album. For audio, the album alone builds the complete design — cover art, tracklist sides, QR code — and style.font / labelColor / background restyle it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) it discloses the required scope ('needs an API key with design:write'), a side effect ('Images are copied into the design – safe to delete from the library afterwards'), and deferred behavior (thumbnail/snapshot only captured on the owner's first browser open-and-save). This is meaningful context an agent could not infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and link-return are front-loaded, followed by the compose_design equivalence, the auth requirement, the when-to-use rule and two behavioral notes. Every sentence carries information; the closing 'say so' is slightly instruction-like but still purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, deeply nested mutation tool with no output schema, the description covers the operation, the returned link, auth scope, side effects and deferred capture. The only thin spot is that parameter-level detail is left almost entirely to the rich schema, which is acceptable here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (78%) and the schema documents name, format, content, images, decals, texts, style and layout in depth. The description adds only the cross-reference that the fields match compose_design 'plus a name', which is useful orientation but not new semantic detail; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('save a design straight to the user's dashboard and return its link') and explicitly names the sibling it relates to ('Takes the SAME fields as compose_design plus a name'), so the agent can separate it from compose_design.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-to-use condition ('when the user wants the design kept on their account without opening a link first'), which implicitly positions compose_design as the ephemeral alternative. It stops short of an explicit when-not statement, so it is strong but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a movie, TV show, or music album by title and return candidate matches with years. Use when the user's title is ambiguous and you want to confirm which one they mean before composing.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | movie, tv, or album | |
| query | Yes | Title to search for, e.g. "Predator 1987" or "Michael Jackson Thriller" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful detail that it returns candidate matches with years (a non-exhaustive lookup), but says nothing about result limits, ranking, or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states the action and return, the second states the usage condition. Front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description covers purpose, return shape, and usage trigger adequately. It could note expected result cardinality or ambiguity handling, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (including the type enum) are already documented in the schema. The description reinforces that lookup is by title but adds no format or syntax guidance beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (look up) and resource (movie, TV show, album by title), and clarifies the return shape ('candidate matches with years'). An agent can distinguish this from get_content and the design-oriented siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the triggering condition: use when the user's title is ambiguous and you want to confirm which one they mean before composing. It implies the compose_design follow-up but does not explicitly name alternatives or when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put an image into the user's Uploads library ("Your Uploads" in every picker) and get back a ref for the images.* fields of compose_design / save_design. Needs an API key with design:write. Send the file as base64 (JPEG/PNG/WebP, at the panel size describe_format reports). SIZE: the request body may not exceed 4.5 MB, so keep the base64 under 3 MB (~2.2 MB of image); a file up to 4 MB goes through POST https://vhs.texs.org/api/v1/uploads as multipart instead — re-encode as JPEG quality 80–85 before either. Identical bytes already in the library return the existing item instead of a copy. The library has a per-plan image count (get_account → uploads); at the ceiling the call answers LIBRARY_IMAGE_LIMIT — call list_uploads and delete_upload to make room.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Base64 of the image bytes (no data: prefix needed; one is tolerated) | |
| name | No | A filename or label shown in the library, e.g. "predator-front.png" | |
| mimeType | Yes | e.g. image/png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the required API scope, concrete size ceilings (4.5 MB body, 3 MB base64, ~2.2 MB image), dedup behavior for identical bytes, a per-plan quota sourced from get_account, and the specific LIBRARY_IMAGE_LIMIT failure with a remediation path. The openWorldHint=false claim is consistent with a closed library.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose and the return contract before the operational constraints, and every sentence carries non-obvious information. It is dense and somewhat run-on with parentheticals, but there is little that could be cut without losing a constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still names the return value (a ref for images.* fields), and it covers auth, size, dedup, quota, error code, and workaround. An agent has everything needed to invoke this successfully on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real constraint value: it explains the base64 payload limit and the panel-size target from describe_format, and recommends JPEG quality 80-85. It does not reconcile the schema's broader mimeType enum (gif, avif, heic, bmp, tiff) against the JPEG/PNG/WebP it names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (put an image into the user's Uploads library) and connects the result to a concrete downstream use (a ref for the images.* fields of compose_design / save_design). This clearly separates it from siblings like list_uploads, delete_upload, and describe_format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly covers when to use the base64 path vs. the 4 MB multipart endpoint, the required design:write scope, the re-encode-to-JPEG step before either path, and exactly which tools to reach for at the library ceiling (list_uploads, delete_upload). Nothing about routing or prerequisites is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compose_design2 fields changedInput schema / properties / style / properties / productionLogoColorAdded value: +{
+ "description": "6-digit hex the studio logos are painted with ('tint' / 'solid'); absent = the label colour.",
+ "type": "string"
+}Input schema / properties / style / properties / productionLogoColorizeAdded value: +{
+ "description": "Video formats: how the studio logos (style.productionLogos or the title's own) are painted. 'solid' (the default) fills them flat in the label colour — a full-colour mark like RCA/Columbia becomes a plain shape; 'off' keeps their original colours; 'tint' recolours while keeping shading.",
+ "enum": [
+ "off",
+ "tint",
+ "solid"
+ ],
+ "type": "string"
+}save_design2 fields changedInput schema / properties / style / properties / productionLogoColorAdded value: +{
+ "description": "6-digit hex the studio logos are painted with ('tint' / 'solid'); absent = the label colour.",
+ "type": "string"
+}Input schema / properties / style / properties / productionLogoColorizeAdded value: +{
+ "description": "Video formats: how the studio logos (style.productionLogos or the title's own) are painted. 'solid' (the default) fills them flat in the label colour — a full-colour mark like RCA/Columbia becomes a plain shape; 'off' keeps their original colours; 'tint' recolours while keeping shading.",
+ "enum": [
+ "off",
+ "tint",
+ "solid"
+ ],
+ "type": "string"
+}list_designs3 fields changedInput schema / properties / formatAdded value: +{
+ "description": "Only designs of this format slug (list_formats)",
+ "type": "string"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Skip this many (newest first). Use nextOffset from the previous page.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / queryAdded value: +{
+ "description": "Case-insensitive match on the design name or content title",
+ "type": "string"
+}compose_design1 field changedInput schema / properties / layout / properties / spine2Added value: +{
+ "additionalProperties": false,
+ "properties": {
+ "title": {
+ "description": "Turns on Dual Spine and gives the second spine its own title: 'text' prints the title as text there, 'logo' paints the provider's wordmark. The first spine keeps style.useLogo / text.title. Formats with a second spine only (slipcover, doublevhs, betamax, compact-tape, bluray-slipcover, cardbox); elsewhere reported unsupported.",
+ "enum": [
+ "text",
+ "logo"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "title"
+ ],
+ "type": "object"
+}export_design2 fields changedInput schema / properties / output / descriptionPrevious value: -"'png' (default) or 'pdf'"New value: +"'preview' to see the design, 'png' (default) or 'pdf' for the print file"Input schema / properties / output / enumPrevious value: -[
- "png",
- "pdf"
-]New value: +[
+ "png",
+ "pdf",
+ "preview"
+]save_design1 field changedInput schema / properties / layout / properties / spine2Added value: +{
+ "additionalProperties": false,
+ "properties": {
+ "title": {
+ "description": "Turns on Dual Spine and gives the second spine its own title: 'text' prints the title as text there, 'logo' paints the provider's wordmark. The first spine keeps style.useLogo / text.title. Formats with a second spine only (slipcover, doublevhs, betamax, compact-tape, bluray-slipcover, cardbox); elsewhere reported unsupported.",
+ "enum": [
+ "text",
+ "logo"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "title"
+ ],
+ "type": "object"
+}compose_design5 fields changedInput schema / properties / decalsAdded value: +{
+ "description": "Stickers, graphics, shapes and the user's own images placed on the label. Each entry names a catalog decal by id (list_decals) OR an upload by ref (upload_image; needs the API key). x/y are percent of the sheet (center-anchored; see describe_format → placement for the coordinate space and the size units). Size with `width` (percent of the sheet width) where describe_format accepts it, else `scale`.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "color": {
+ "description": "6-digit hex for colorize (default: the label colour)",
+ "type": "string"
+ },
+ "colorize": {
+ "description": "Paint the decal one colour: 'tint' keeps its shading, 'solid' flattens it",
+ "enum": [
+ "tint",
+ "solid"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "description": "A decal id from list_decals (e.g. \"rcacolumbia!\", \"04-rounded-rectangle\")",
+ "type": "string"
+ },
+ "layer": {
+ "description": "'over' (default), 'under' the label's text and pictures, or 'background'",
+ "enum": [
+ "over",
+ "under",
+ "background"
+ ],
+ "type": "string"
+ },
+ "ref": {
+ "description": "An upload ref, instead of id",
+ "pattern": "^upload:",
+ "type": "string"
+ },
+ "rotation": {
+ "maximum": 360,
+ "minimum": -360,
+ "type": "integer"
+ },
+ "scale": {
+ "description": "The designer's size unit (100 = natural width ÷ 4 layout units); use instead of width",
+ "maximum": 900,
+ "minimum": 10,
+ "type": "integer"
+ },
+ "side": {
+ "description": "Two-sided formats only",
+ "enum": [
+ "front",
+ "back"
+ ],
+ "type": "string"
+ },
+ "stretch": {
+ "description": "Horizontal stretch, percent of the natural aspect",
+ "maximum": 1000,
+ "minimum": 10,
+ "type": "integer"
+ },
+ "width": {
+ "description": "Rendered width as percent of the sheet width (formats with placement.decals.layoutWidthUnits)",
+ "maximum": 200,
+ "minimum": 1,
+ "type": "number"
+ },
+ "x": {
+ "description": "Center, percent of the sheet width (default 50)",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "y": {
+ "description": "Center, percent of the sheet height (default 50)",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "maxItems": 24,
+ "type": "array"
+}Input schema / properties / layout / properties / hide / descriptionPrevious value: -"Fields to hide on the design"New value: +"Fields to hide on the design (video formats). 'poster' removes the cover art so a panel image or decal can carry the front."Input schema / properties / layout / properties / hide / items / enumPrevious value: -[
- "rating",
- "texsOrg",
- "overview",
- "labelOverview",
- "fbiWarning",
- "rules",
- "pullquote",
- "pullquoteCredit",
- "spineMeta",
- "barcode",
- "qrCode",
- "spineLogo",
- "title",
- "tagline",
- "year",
- "origin",
- "runtime",
- "starring",
- "director",
- "budget",
- "revenue",
- "movieId",
- "seasonEpisode",
- "writers",
- "composer",
- "producer",
- "productionLogos"
-]New value: +[
+ "poster",
+ "rating",
+ "texsOrg",
+ "overview",
+ "labelOverview",
+ "fbiWarning",
+ "rules",
+ "pullquote",
+ "pullquoteCredit",
+ "spineMeta",
+ "barcode",
+ "qrCode",
+ "spineLogo",
+ "title",
+ "tagline",
+ "year",
+ "origin",
+ "runtime",
+ "starring",
+ "director",
+ "budget",
+ "revenue",
+ "movieId",
+ "seasonEpisode",
+ "writers",
+ "composer",
+ "producer",
+ "productionLogos"
+]Input schema / properties / style / properties / productionLogosAdded value: +{
+ "description": "Video formats: Classic Logo ids (list_decals → classicLogos, e.g. \"rcacolumbia!\") for the spine and studio slot, in order (#1 is the spine). As the whole selection they REPLACE the title's own studio logos; [] removes the studio slot.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 4,
+ "type": "array"
+}Input schema / properties / textsAdded value: +{
+ "description": "Free text blocks placed on the label (the designer's Text tab). x/y are the block's center in percent of the sheet; width is the percent of the sheet width the block spans (text wraps); size is the font size as percent of the sheet height.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "align": {
+ "enum": [
+ "left",
+ "center",
+ "right"
+ ],
+ "type": "string"
+ },
+ "allCaps": {
+ "type": "boolean"
+ },
+ "color": {
+ "description": "6-digit hex (default: the label colour)",
+ "type": "string"
+ },
+ "font": {
+ "description": "Family name — a curated family or any Google font",
+ "type": "string"
+ },
+ "italic": {
+ "type": "boolean"
+ },
+ "letterSpacing": {
+ "description": "px",
+ "maximum": 50,
+ "minimum": -20,
+ "type": "number"
+ },
+ "lineHeight": {
+ "maximum": 4,
+ "minimum": 0.5,
+ "type": "number"
+ },
+ "rotation": {
+ "maximum": 360,
+ "minimum": -360,
+ "type": "integer"
+ },
+ "side": {
+ "enum": [
+ "front",
+ "back"
+ ],
+ "type": "string"
+ },
+ "size": {
+ "description": "Font size, percent of the sheet height (default 9)",
+ "maximum": 60,
+ "minimum": 0.5,
+ "type": "number"
+ },
+ "text": {
+ "description": "The text; newlines allowed",
+ "type": "string"
+ },
+ "weight": {
+ "maximum": 900,
+ "minimum": 100,
+ "type": "integer"
+ },
+ "width": {
+ "description": "Percent of the sheet width (default 50)",
+ "maximum": 100,
+ "minimum": 10,
+ "type": "integer"
+ },
+ "x": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "y": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "text"
+ ],
+ "type": "object"
+ },
+ "maxItems": 24,
+ "type": "array"
+}get_contentlist_decalssave_design5 fields changedInput schema / properties / decalsAdded value: +{
+ "description": "Stickers, graphics, shapes and the user's own images placed on the label. Each entry names a catalog decal by id (list_decals) OR an upload by ref (upload_image; needs the API key). x/y are percent of the sheet (center-anchored; see describe_format → placement for the coordinate space and the size units). Size with `width` (percent of the sheet width) where describe_format accepts it, else `scale`.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "color": {
+ "description": "6-digit hex for colorize (default: the label colour)",
+ "type": "string"
+ },
+ "colorize": {
+ "description": "Paint the decal one colour: 'tint' keeps its shading, 'solid' flattens it",
+ "enum": [
+ "tint",
+ "solid"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "description": "A decal id from list_decals (e.g. \"rcacolumbia!\", \"04-rounded-rectangle\")",
+ "type": "string"
+ },
+ "layer": {
+ "description": "'over' (default), 'under' the label's text and pictures, or 'background'",
+ "enum": [
+ "over",
+ "under",
+ "background"
+ ],
+ "type": "string"
+ },
+ "ref": {
+ "description": "An upload ref, instead of id",
+ "pattern": "^upload:",
+ "type": "string"
+ },
+ "rotation": {
+ "maximum": 360,
+ "minimum": -360,
+ "type": "integer"
+ },
+ "scale": {
+ "description": "The designer's size unit (100 = natural width ÷ 4 layout units); use instead of width",
+ "maximum": 900,
+ "minimum": 10,
+ "type": "integer"
+ },
+ "side": {
+ "description": "Two-sided formats only",
+ "enum": [
+ "front",
+ "back"
+ ],
+ "type": "string"
+ },
+ "stretch": {
+ "description": "Horizontal stretch, percent of the natural aspect",
+ "maximum": 1000,
+ "minimum": 10,
+ "type": "integer"
+ },
+ "width": {
+ "description": "Rendered width as percent of the sheet width (formats with placement.decals.layoutWidthUnits)",
+ "maximum": 200,
+ "minimum": 1,
+ "type": "number"
+ },
+ "x": {
+ "description": "Center, percent of the sheet width (default 50)",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "y": {
+ "description": "Center, percent of the sheet height (default 50)",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "maxItems": 24,
+ "type": "array"
+}Input schema / properties / layout / properties / hide / descriptionPrevious value: -"Fields to hide on the design"New value: +"Fields to hide on the design (video formats). 'poster' removes the cover art so a panel image or decal can carry the front."Input schema / properties / layout / properties / hide / items / enumPrevious value: -[
- "rating",
- "texsOrg",
- "overview",
- "labelOverview",
- "fbiWarning",
- "rules",
- "pullquote",
- "pullquoteCredit",
- "spineMeta",
- "barcode",
- "qrCode",
- "spineLogo",
- "title",
- "tagline",
- "year",
- "origin",
- "runtime",
- "starring",
- "director",
- "budget",
- "revenue",
- "movieId",
- "seasonEpisode",
- "writers",
- "composer",
- "producer",
- "productionLogos"
-]New value: +[
+ "poster",
+ "rating",
+ "texsOrg",
+ "overview",
+ "labelOverview",
+ "fbiWarning",
+ "rules",
+ "pullquote",
+ "pullquoteCredit",
+ "spineMeta",
+ "barcode",
+ "qrCode",
+ "spineLogo",
+ "title",
+ "tagline",
+ "year",
+ "origin",
+ "runtime",
+ "starring",
+ "director",
+ "budget",
+ "revenue",
+ "movieId",
+ "seasonEpisode",
+ "writers",
+ "composer",
+ "producer",
+ "productionLogos"
+]Input schema / properties / style / properties / productionLogosAdded value: +{
+ "description": "Video formats: Classic Logo ids (list_decals → classicLogos, e.g. \"rcacolumbia!\") for the spine and studio slot, in order (#1 is the spine). As the whole selection they REPLACE the title's own studio logos; [] removes the studio slot.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 4,
+ "type": "array"
+}Input schema / properties / textsAdded value: +{
+ "description": "Free text blocks placed on the label (the designer's Text tab). x/y are the block's center in percent of the sheet; width is the percent of the sheet width the block spans (text wraps); size is the font size as percent of the sheet height.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "align": {
+ "enum": [
+ "left",
+ "center",
+ "right"
+ ],
+ "type": "string"
+ },
+ "allCaps": {
+ "type": "boolean"
+ },
+ "color": {
+ "description": "6-digit hex (default: the label colour)",
+ "type": "string"
+ },
+ "font": {
+ "description": "Family name — a curated family or any Google font",
+ "type": "string"
+ },
+ "italic": {
+ "type": "boolean"
+ },
+ "letterSpacing": {
+ "description": "px",
+ "maximum": 50,
+ "minimum": -20,
+ "type": "number"
+ },
+ "lineHeight": {
+ "maximum": 4,
+ "minimum": 0.5,
+ "type": "number"
+ },
+ "rotation": {
+ "maximum": 360,
+ "minimum": -360,
+ "type": "integer"
+ },
+ "side": {
+ "enum": [
+ "front",
+ "back"
+ ],
+ "type": "string"
+ },
+ "size": {
+ "description": "Font size, percent of the sheet height (default 9)",
+ "maximum": 60,
+ "minimum": 0.5,
+ "type": "number"
+ },
+ "text": {
+ "description": "The text; newlines allowed",
+ "type": "string"
+ },
+ "weight": {
+ "maximum": 900,
+ "minimum": 100,
+ "type": "integer"
+ },
+ "width": {
+ "description": "Percent of the sheet width (default 50)",
+ "maximum": 100,
+ "minimum": 10,
+ "type": "integer"
+ },
+ "x": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "y": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "text"
+ ],
+ "type": "object"
+ },
+ "maxItems": 24,
+ "type": "array"
+}delete_uploadlist_uploadscompose_design1 field changedInput schema / properties / imagesAdded value: +{
+ "additionalProperties": false,
+ "description": "The user's own artwork by upload ref (from upload_image). Needs the API key that owns the uploads. Single-surface formats only (describe_format → singleSurface). Each value is a ref string or { ref, fit, opacity }.",
+ "properties": {
+ "background": {
+ "description": "One image over the whole sheet (all panels).",
+ "oneOf": [
+ {
+ "pattern": "^upload:",
+ "type": "string"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "fit": {
+ "enum": [
+ "fit",
+ "fill",
+ "stretch"
+ ],
+ "type": "string"
+ },
+ "opacity": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "ref": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "logo": {
+ "description": "A custom studio / production logo (video formats). It replaces the title's own studio logos on the spine and back panel. Upload a transparent PNG.",
+ "pattern": "^upload:",
+ "type": "string"
+ },
+ "panels": {
+ "additionalProperties": {
+ "oneOf": [
+ {
+ "pattern": "^upload:",
+ "type": "string"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "fit": {
+ "enum": [
+ "fit",
+ "fill",
+ "stretch"
+ ],
+ "type": "string"
+ },
+ "opacity": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "ref": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "description": "Per-panel images keyed by the panel key describe_format reports (e.g. front, back, spine1). Unknown keys come back as unsupported.",
+ "type": "object"
+ }
+ },
+ "type": "object"
+}delete_designdescribe_formatexport_designget_accountget_designget_exportlist_designssave_designupload_imagecompose_design1 field changedInput schema / properties / format / enumPrevious value: -[
- "slipcover",
- "side-load-vhs",
- "doublevhs",
- "betamax",
- "compact-tape",
- "bluray-cover",
- "bluray-slipcover",
- "dvd-cover",
- "clamshell",
- "polycase",
- "cardbox",
- "disc",
- "cassette",
- "cassingle",
- "jcard",
- "cd",
- "cd-tray",
- "cd-insert",
- "vinyl-label",
- "vinyl-jacket",
- "vinyl-sleeve",
- "minidisc-label",
- "minidisc-full-labels",
- "minidisc-jcard",
- "minidisc-cover",
- "minidisc-tray"
-]New value: +[
+ "slipcover",
+ "side-load-vhs",
+ "doublevhs",
+ "betamax",
+ "compact-tape",
+ "bluray-cover",
+ "bluray-slipcover",
+ "dvd-cover",
+ "steelcase",
+ "clamshell",
+ "polycase",
+ "cardbox",
+ "disc",
+ "cassette",
+ "cassingle",
+ "jcard",
+ "cd",
+ "cd-tray",
+ "cd-insert",
+ "vinyl-label",
+ "vinyl-jacket",
+ "vinyl-sleeve",
+ "minidisc-label",
+ "minidisc-full-labels",
+ "minidisc-jcard",
+ "minidisc-cover",
+ "minidisc-tray"
+]compose_design1 field changedInput schema / properties / format / enumPrevious value: -[
- "slipcover",
- "side-load-vhs",
- "doublevhs",
- "betamax",
- "compact-tape",
- "bluray-cover",
- "bluray-slipcover",
- "dvd-cover",
- "clamshell",
- "polycase",
- "cardbox",
- "disc",
- "cassette",
- "cassingle",
- "jcard",
- "cd",
- "cd-tray",
- "cd-insert",
- "vinyl-label",
- "vinyl-jacket",
- "vinyl-sleeve",
- "minidisc-label",
- "minidisc-cover",
- "minidisc-jcard",
- "minidisc-tray",
- "minidisc-full-labels"
-]New value: +[
+ "slipcover",
+ "side-load-vhs",
+ "doublevhs",
+ "betamax",
+ "compact-tape",
+ "bluray-cover",
+ "bluray-slipcover",
+ "dvd-cover",
+ "clamshell",
+ "polycase",
+ "cardbox",
+ "disc",
+ "cassette",
+ "cassingle",
+ "jcard",
+ "cd",
+ "cd-tray",
+ "cd-insert",
+ "vinyl-label",
+ "vinyl-jacket",
+ "vinyl-sleeve",
+ "minidisc-label",
+ "minidisc-full-labels",
+ "minidisc-jcard",
+ "minidisc-cover",
+ "minidisc-tray"
+]compose_design1 field changedInput schema / properties / format / enumPrevious value: -[
- "slipcover",
- "side-load-vhs",
- "doublevhs",
- "betamax",
- "bluray-cover",
- "bluray-slipcover",
- "dvd-cover",
- "clamshell",
- "polycase",
- "cardbox",
- "disc",
- "cassette",
- "cassingle",
- "jcard",
- "cd",
- "cd-tray",
- "cd-insert",
- "vinyl-label",
- "vinyl-jacket",
- "vinyl-sleeve",
- "minidisc-label",
- "minidisc-cover",
- "minidisc-jcard",
- "minidisc-tray",
- "minidisc-full-labels"
-]New value: +[
+ "slipcover",
+ "side-load-vhs",
+ "doublevhs",
+ "betamax",
+ "compact-tape",
+ "bluray-cover",
+ "bluray-slipcover",
+ "dvd-cover",
+ "clamshell",
+ "polycase",
+ "cardbox",
+ "disc",
+ "cassette",
+ "cassingle",
+ "jcard",
+ "cd",
+ "cd-tray",
+ "cd-insert",
+ "vinyl-label",
+ "vinyl-jacket",
+ "vinyl-sleeve",
+ "minidisc-label",
+ "minidisc-cover",
+ "minidisc-jcard",
+ "minidisc-tray",
+ "minidisc-full-labels"
+]compose_designlist_formatssearch_contentTrim, convert, resize, compress, and remix audio and video.
Transform video, audio and images, and generate media from prompts. FFmpeg, captions, models.
Compose, save and print music box tunes for 15, 20 and 30-note music boxes.
Make podcasts, video shows, audio drama, and documentaries just by chatting. Script to episode.
Add one secure layer between your agents and this server.
