Skip to main content
Glama
thenavidm

Shotstack MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Generation Models

list_models
Read-onlyIdempotent

Retrieve generation models available for image, video, and audio prompts, with options and credit costs, to build model pickers and keep choices current.

Instructions

List the generation models available for prompt-bearing image, video and audio assets, with the options each accepts and what it costs in credits.

Use this to populate a model picker and render its option fields, rather than hard coding a model list. A newly launched model appears here without any change on your side. Each entry carries the asset type it generates, so filter the list client side when a picker only needs one kind.

Option schemas are omitted by default. Request them with expand=options.

Each model's available reflects the plan of the account behind the calling API key, so offer only the models it marks available.

Base URL: https://api.shotstack.io/edit/{version} Read operation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountNoNamed private Shotstack account; selects private credentials and stage/v1 environment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable behavior beyond that: option schemas are omitted by default and require `expand=options`, and the `available` field reflects the calling API key's plan, which affects what should be shown. Some context like pagination or rate limits is not mentioned, but the key operational detail is disclosed.

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?

The description is front-loaded with purpose, then usage, then behavior details, and ends with base URL and read-operation note. It is a bit long but every sentence contributes useful context; no obvious filler.

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

Completeness4/5

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

Given no output schema, the description explains the shape of returned data (asset type, options, availability) and the default omission of option schemas. It could mention pagination or response ordering, but overall it gives enough for an agent to call and interpret the tool correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the `account` parameter is fully documented in the schema. The description adds no parameter syntax or default-value information beyond the schema, so baseline 3 is appropriate. It does mention the `expand=options` behavior, but that is not a formal parameter in this schema.

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

Purpose5/5

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

The description states a specific verb (List) and resource (generation models available for prompt-bearing image, video, and audio assets), with the added scope that each entry carries its asset type and options. It clearly distinguishes itself from siblings like get_model (singular) and list_templates by naming what it returns and why it exists.

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?

It gives a concrete when-to-use case (populate a model picker, avoid hard coding) and explains that filtering by asset type should be done client side. It doesn't name a sibling alternative or explicitly state when-not-to-use, but the usage context is strong.

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

Deploy Server

Other Tools