AwesomeVideo

Read the AwesomeVideo catalog

get_catalog

Read-onlyIdempotent

Free, read-only, works without a key. Everything you can choose from, by kind: presets (built-in, approved community and, with a key, your custom presets, plus bundled fonts), styles (every caption style field with type, range and examples), voices (dub voices with tier, price and sampleUrl; filter with language and tier), platforms (where videos are posted, with safe zones), audio_visuals (the ten editorial podcast designs for audio-only input). Paginated with limit and cursor; response_format concise (default) drops nested objects such as full style JSON, detailed returns them. Pass ids you find here as preset, voice, platform or audioVisual to the job tools.

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": {
      "kind": "<kind>"
    },
    "name": "get_catalog"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	Which catalog: presets, styles, voices, platforms or audio_visuals.
`tier`	No	'basic' (5 credits/min) or 'standard' (12 credits/min). Omit for both.
`limit`	No	Page size for the returned list, 1-100. Default 50.
`cursor`	No	nextCursor from the previous page. Omit for the first page.
`language`	No	Only voices for this language (ISO 639-1, e.g. es). Omit for all languages.
`response_format`	No	concise (default): short list items without nested style/example objects, to save tokens. detailed: full objects.

Output Schema

Name	Required	Description
`total`	No	Total number of items (paginated lists).
`result`	No	The value, when the tool returns something other than an object.
`hasMore`	No	true when more items are available (paginated lists).
`nextCursor`	No	Pass as cursor for the next page (paginated lists).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, the description adds important operational context: it is free and read-only, works without a key, custom presets require a key, pagination uses limit and cursor, and response_format affects nested objects and token usage. This gives the agent substantial behavioral context not captured by annotations alone.

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

Conciseness5/5

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

The description is front-loaded with access and safety traits, then proceeds through catalog kinds and invocation details. Despite being dense, every sentence provides useful selection or usage information without filler.

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?

Given the rich annotations, 100% schema coverage, and an output schema, the description supplies all remaining context an agent needs: access requirements, catalog contents, pagination, response format tradeoffs, and how to use returned IDs.

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 already 100%, but the description adds useful meaning: it lists what each kind contains, explains voices filtering by language and tier, and clarifies the concise versus detailed response formats. The added value is meaningful, though much of it overlaps with schema descriptions.

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?

The description clearly states that this tool reads a catalog and enumerates the five kinds of catalog data. It does not explicitly distinguish the tool from the sibling get_presets, especially for presets, so it falls short of full sibling differentiation.

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 explains the discovery use case: find IDs here and pass them as preset, voice, platform, or audioVisual to job tools. It also notes filtering and pagination behavior, but it does not explicitly say when to use this instead of get_presets or other siblings.

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

All AwesomeVideo 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?