The Ssemble MCP Server lets AI assistants create and manage AI-generated short-form video clips from YouTube videos or uploaded files using Ssemble's AI clipping engine.
Create short-form videos (create_short): Submit a YouTube URL or file URL with a time range to generate AI-clipped shorts. Supports background music, gameplay overlays, meme hooks, animated hook titles, caption templates, CTA text, layout framing (auto/fill/fit/square), spoken and caption language selection, preferred clip length, and webhook callbacks.
Check processing status (get_status): Monitor request progress (queued → processing → completed/failed) with a percentage and step description.
Retrieve completed clips (get_shorts): Fetch generated shorts including video URLs, AI-generated titles, descriptions, viral scores, and durations.
List all requests (list_requests): Browse your request history with filtering by status, pagination, and sorting.
Delete a request (delete_request): Permanently remove a request and all associated videos (irreversible; credits are not refunded).
Browse assets: Explore available caption style templates (list_templates), background music tracks (list_music), gameplay overlay videos (list_game_videos), and meme hook clips (list_meme_hooks).
Automate workflows: Receive webhook callbacks on completion or failure for use with tools like n8n, Zapier, or Make.
Integrate with MCP-compatible clients including Claude Desktop, Claude Code, Cursor, VS Code, and Windsurf.
Allows for the creation of AI-generated short-form video clips from YouTube URLs, including features to track processing progress, retrieve completed clips with viral scores, and manage video requests.
MCP server for Ssemble AI Clipping — create viral short-form videos from any AI assistant.
Works with Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and any MCP-compatible client.
This MCP server lets AI assistants create short-form video clips from YouTube videos using Ssemble's AI clipping engine. The AI can:
Create shorts from YouTube URLs or uploaded files
Webhook callbacks — get notified when processing completes (works with n8n, Zapier, Make)
Browse assets — caption templates, background music, gameplay overlays, meme hooks
Track processing — check progress and retrieve completed clips
Manage requests — list history, get results, delete old requests
Related MCP server: clipwise-mcp
Ssemble account with an active subscription
API key (get it from Settings → API Keys in the Ssemble dashboard)
Node.js >= 18
Edit your config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"ssemble": {
"command": "npx",
"args": ["@ssemble/mcp-server"],
"env": {
"SSEMBLE_API_KEY": "sk_ssemble_your_key_here"
}
}
}
}Restart Claude Desktop after saving.
claude mcp add ssemble -- npx @ssemble/mcp-serverThen set the environment variable:
export SSEMBLE_API_KEY="sk_ssemble_your_key_here"Add to your MCP settings:
{
"mcpServers": {
"ssemble": {
"command": "npx",
"args": ["@ssemble/mcp-server"],
"env": {
"SSEMBLE_API_KEY": "sk_ssemble_your_key_here"
}
}
}
}Tool | Description |
| Create AI-generated short clips from a video. Returns request ID instantly. |
| Check processing progress (0-100%) and current step |
| Retrieve completed clips with video URLs, titles, viral scores |
| List all your requests with pagination and status filtering |
| Permanently delete a request and its videos |
| Browse caption style templates |
| Browse background music tracks |
| Browse gameplay overlay videos |
| Browse meme hook attention-grabber clips |
Video processing takes 5-30 minutes. Two workflows available:
create_short — submits the job and returns instantly with a request ID
get_status — check progress anytime (queued → processing → completed)
get_shorts — retrieve the generated clips when done
create_short with webhookUrl — submits the job with a callback URL
When processing completes or fails, the API sends an HTTP POST to your URL with the results
No polling needed — ideal for n8n, Zapier, Make, and custom backend integrations
Webhook payload example:
{
"event": "shorts.completed",
"requestId": "507f1f77bcf86cd799439011",
"status": "completed",
"timestamp": "2026-03-30T12:00:00.000Z",
"data": {
"shorts": [
{
"id": "...",
"title": "AI-Generated Title",
"video_url": "https://...",
"duration": 45,
"viral_score": 8.5
}
]
}
}Create shorts from a YouTube video:
"Create shorts from https://youtube.com/watch?v=abc123, use the first 10 minutes with chill background music"
Browse available assets:
"Show me all caption templates" / "What background music is available?"
Check progress:
"What's the status of my video request?"
Get results:
"Show me the clips for request 507f1f77bcf86cd799439011, sorted by viral score"
Variable | Required | Description |
| Yes | Your Ssemble API key (starts with |
| No | Override API base URL (default: |
git clone https://gitlab.com/vlogr/ssemble-mcp-server.git
cd ssemble-mcp-server
npm install
SSEMBLE_API_KEY=sk_ssemble_your_key npm startMIT
Create AI-generated short-form video clips from a YouTube video or uploaded file. Returns a request ID instantly. Processing takes 5-30 minutes. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | YouTube video URL | |
| fileUrl | No | Public video file URL (alternative to url) | |
| start | Yes | Start time in seconds (>= 0) | |
| end | Yes | End time in seconds (> start, max 1200s window) | |
| preferredLength | No | Target clip duration | under60sec |
| language | No | Spoken language (ISO 639-1) | en |
| captionLanguage | No | Caption language if different from spoken | |
| templateId | No | Caption template ID from list_templates (24-char hex) | |
| noClipping | No | Skip AI clipping, process entire range as one clip | |
| hookTitle | No | Add animated hook title at start | |
| memeHook | No | Prepend a meme hook clip (2-5s attention grabber) | |
| memeHookName | No | Exact meme hook name from list_meme_hooks (case-sensitive) | |
| gameVideo | No | Add split-screen gameplay overlay | |
| gameVideoName | No | Exact game video name from list_game_videos (case-sensitive) | |
| ctaEnabled | No | Show call-to-action text overlay | |
| ctaText | No | CTA text (max 200 chars, required when ctaEnabled=true) | |
| music | No | Add background music | |
| musicName | No | Exact track name from list_music (case-sensitive) | |
| musicVolume | No | Music volume 0-100 | |
| layout | No | Video framing layout | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses critical behavioral traits: async processing (returns ID instantly, 5-30min processing time) and cost model (1 credit). Could mention idempotency or failure modes.
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 sentences with zero waste: purpose, return value, processing time, and cost. Front-loaded with the core action. Every sentence 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?
For a complex 20-parameter tool with 100% schema coverage, the description appropriately focuses on async return pattern and cost rather than repeating parameter docs. Lacks mention of status polling requirement (get_status) preventing a 5.
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 has 100% description coverage, establishing baseline 3. Description mentions 'YouTube video or uploaded file' which loosely maps to url/fileUrl parameters, but adds minimal semantic value beyond what the schema already 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?
Specific verb 'Create' + resource 'AI-generated short-form video clips' + source types 'YouTube video or uploaded file'. Clearly distinguishes from sibling list/get/delete 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?
Implies async workflow via 'Returns a request ID instantly' and processing time, but fails to mention prerequisite sibling tools (list_templates, list_meme_hooks, etc.) required for parameters like templateId and memeHookName.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a short creation request and all generated videos. Credits are NOT refunded. This action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | The request ID to delete (24-char hex). This action is irreversible and credits are NOT refunded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavior disclosure. It explicitly states the action is permanent, deletes associated videos, and credits are not refunded, which are critical operational consequences.
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?
The description is brief and front-loaded with the core action, followed by essential warnings. Every sentence adds value without redundancy.
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 delete tool with no output schema, the description covers purpose, side effects, and irreversibility. It is contextually complete for an agent to decide whether and how to invoke.
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 schema already covers the parameter fully with description and pattern, so the high schema coverage sets a baseline of 3. The tool description adds no additional parameter semantics beyond what the schema states.
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 specifies the verb 'delete', the resource 'short creation request', and the scope 'all generated videos', clearly distinguishing it from sibling create/list/get 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?
The description provides clear context: it's for permanent deletion with irreversible consequences. The warning about non-refundable credits and irreversibility implicitly advises caution, but it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all generated short clips for a completed request. Returns video URLs, AI-generated titles, descriptions, viral scores, and durations sorted by viral score.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | The request ID from create_short (24-char hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses specific return fields (video URLs, AI-generated titles, viral scores, durations) and critical behavioral trait: results are 'sorted by viral score'. Missing error behavior for incomplete requests or invalid IDs.
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 efficient sentences with zero waste. Front-loaded with action ('Retrieve'), followed by scope ('for a completed request'), then return value specification. Every word 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?
No output schema exists, but description compensates by detailing the complete response structure (URLs, titles, scores, durations) and sorting behavior. Lacks only error-state documentation for a fully complete picture.
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 has 100% description coverage (requestId documented as 24-char hex), establishing baseline 3. Description references 'completed request' implying the parameter context but does not add syntax, format, or usage details 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?
Specific verb 'Retrieve' + resource 'short clips' + scope 'for a completed request'. Clearly distinguishes from sibling create_short (creates vs retrieves) and get_status (gets content vs status).
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?
Implies usage timing with 'completed request', suggesting it should not be used on pending requests. However, lacks explicit guidance to use sibling get_status first to check completion, or explicit when-not-to-use warnings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check processing status and progress of a short creation request. Returns status (queued/processing/completed/failed), progress percentage, and current step.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | The request ID from create_short (24-char hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return structure comprehensively: enumerates status values (queued/processing/completed/failed), mentions progress percentage and current step. Missing error behavior (e.g., invalid requestId) and read-only nature, but effectively compensates for absent output schema.
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 with zero waste. First sentence defines action and scope; second sentence discloses return values. Front-loaded with essential information, no redundant phrases.
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?
Appropriate for tool complexity (single param, 100% schema coverage, simple behavior). Description adequately compensates for missing output schema by detailing return structure. Links to sibling create_short via 'short creation request' context, completing the operational picture.
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% with requestId fully documented (type, pattern, description linking to create_short). Description does not mention parameters, but baseline of 3 is appropriate when schema documentation is complete; no additional parameter semantics needed in description.
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?
Clear specific verb 'Check' with explicit resource 'processing status and progress of a short creation request'. Distinguishes from sibling get_shorts (which returns content) and list_requests (which lists multiple) by focusing on detailed progress polling of a single creation job.
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?
Implies usage context by referencing 'short creation request' and status lifecycle (queued/processing/completed/failed), suggesting polling workflow after create_short. Lacks explicit 'when to use vs alternatives' statement (e.g., contrasting with list_requests), but context is clear from description and parameter schema reference to create_short.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available gameplay videos for split-screen overlays (content top, game bottom). Use the exact gameVideoName when creating shorts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Items per page (1-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It adds valuable behavioral context about the split-screen layout (content top, game bottom) and hints at output structure (gameVideoName field), but omits pagination behavior details, rate limits, or response format specifics expected for a read operation with no safety 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 with zero waste. First sentence front-loads purpose and specific domain context; second sentence provides actionable usage guidance. Every word 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?
For a simple 2-parameter list tool with no output schema, the description adequately compensates by revealing the key output field (gameVideoName) and the specific domain (split-screen overlays). Slight gap on pagination return structure (total counts, hasMore flags), but sufficient for tool selection.
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% (page number and items per page are clearly documented), so the baseline expectation is met. The description does not add parameter-specific semantics, but none are needed given the comprehensive schema documentation.
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 uses specific verb 'List' with clear resource 'gameplay videos' and distinguishes from siblings by specifying the unique use case 'for split-screen overlays (content top, game bottom)', clearly differentiating it from list_music, list_templates, and other list 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?
Provides explicit guidance on when/how to use the output ('Use the exact gameVideoName when creating shorts'), referencing the sibling tool create_short. However, it lacks explicit 'when not to use' guidance or contrast with alternative tools like list_templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available meme hook clips (2-5 second attention grabbers prepended to shorts). Use the exact memeHookName when creating shorts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Items per page (1-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It adds domain context explaining what meme hooks are (duration, purpose), but omits safety profile (read-only vs mutation), rate limits, or pagination behavior details that annotations would normally cover.
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 with zero waste: first defines resource and its characteristics, second provides usage workflow guidance. Every word earns its place; appropriately front-loaded.
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 listing tool with no output schema, description compensates by identifying the key output field to capture (memeHookName) for use with create_short. Covers pagination via schema. Good completeness for a simple list operation.
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 has 100% description coverage with clear pagination parameter descriptions ('Page number', 'Items per page'). Description adds no parameter-specific guidance, which is acceptable given schema completeness, meeting baseline expectation.
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?
Description provides specific verb 'List' with resource 'meme hook clips', defines what they are (2-5 second attention grabbers prepended to shorts), and distinguishes from siblings like list_music or list_templates by specifying the unique clip type and its relationship to video creation.
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 connects to sibling workflow by stating to 'Use the exact memeHookName when creating shorts', establishing when/why to use this tool (to get valid names for create_short). Lacks explicit 'when not to use' or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available background music tracks with names and durations. Use the exact musicName when creating shorts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Items per page (1-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses output structure ('names and durations') which compensates for the missing output schema. However, it omits safety/disposition details (e.g., read-only nature) and pagination behavior despite having pagination parameters.
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, both earning their place: the first declares purpose and output, the second provides critical usage context for the downstream workflow. No redundancy or filler content.
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 low-complexity tool (2 optional params, no nested objects) without an output schema, the description appropriately compensates by specifying the return values ('names and durations'). It also connects the output to the 'create_short' workflow. Could mention pagination implications, but schema coverage mitigates this 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 description coverage is 100% (page and limit are fully documented), establishing a baseline of 3. The description does not add semantic meaning beyond the schema (e.g., it doesn't explain pagination strategy or defaults), so it meets but does not exceed the baseline.
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 provides a specific verb ('List') + resource ('background music tracks') + return details ('names and durations'). It clearly distinguishes from sibling list tools (list_game_videos, list_meme_hooks, list_templates) by specifying 'background music'.
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?
The second sentence provides explicit usage guidance: 'Use the exact musicName when creating shorts.' This establishes the relationship to sibling tool 'create_short' and tells the agent when to invoke this tool (to get valid music names for short creation). Lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all short creation requests with optional status filtering, pagination, and sorting.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Items per page (1-100) | |
| status | No | Filter by status | |
| sortBy | No | Sort field | createdAt |
| sortOrder | No | Sort direction | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does not explicitly state that the operation is read-only, nor does it disclose potential side effects, response shapes, or rate limits. The word 'List' implies safety, but the description adds little behavioral context beyond what the name already conveys.
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?
The description is a single sentence of 11 words, front-loading the core action ('List all short creation requests') and then listing the optional features. Every word earns its place; no fluff or repetition.
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?
The tool has no output schema and no annotations, so the description should explain what the response looks like or note limitations, but it does not. It covers the basic functionality and parameters adequately, but an agent may not know the return format or potential edge cases (e.g., empty results). This is a clear gap, making it merely viable.
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 schema provides 100% coverage of all five parameters with clear types, defaults, and descriptions. The description merely summarizes the parameters (status filtering, pagination, sorting) without adding new meaning, so it stays at 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?
The description states a specific verb ('List') and a clear resource ('short creation requests'), which distinguishes it from sibling tools like list_music or list_templates. It also mentions optional status filtering, pagination, and sorting, giving a precise scope of functionality.
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?
The description implies usage: it is the tool for listing short creation requests with optional filters and sorting. However, it does not explicitly mention when to prefer this over alternatives (e.g., get_status for a single request status) or provide exclusions, so guidance is only inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available caption style templates with IDs and names. Use the templateId when creating shorts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses what data is returned ('IDs and names'), helping predict output structure. However, missing safety/permission info, pagination behavior, or rate limits that would be essential for a production tool with no annotation coverage.
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 with zero waste. First sentence establishes purpose and return value; second provides usage context. Front-loaded structure with every sentence earning 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?
Given zero parameters and no output schema, description adequately compensates by specifying return fields ('IDs and names'). Sufficient for low-complexity tool, though could mention pagination or total volume limits for complete production context.
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?
Input schema contains zero parameters. Per rubric guidelines, zero-parameter tools receive baseline score of 4. Description appropriately does not invent parameter semantics where none exist.
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?
Description provides specific verb ('List'), resource ('caption style templates'), scope ('all available'), and return fields ('IDs and names'). Clearly distinguishes from sibling list tools (list_music, list_game_videos) by specifying 'caption style' 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?
Second sentence establishes workflow connection to sibling tool create_short ('Use the templateId when creating shorts'), implying when to invoke this tool. Lacks explicit 'when not to use' or comparison to alternative listing tools, but provides clear contextual purpose.
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.
v1.0.4create_shortdelete_requestget_shortsget_statuslist_game_videoslist_meme_hookslist_musiclist_requestslist_templatesScored across 9 tools
Each tool has a distinct, non-overlapping purpose. The four 'list_' tools target different resource types (game videos, meme hooks, music, templates), while lifecycle tools (create_short, get_status, get_shorts, delete_request) clearly separate creation, monitoring, retrieval, and cleanup phases without ambiguity.
Perfect consistency with snake_case verb_noun pattern throughout (create_short, delete_request, get_shorts, get_status, list_requests, etc.). All list operations use the 'list_' prefix, retrieval uses 'get_', and mutation uses 'create_' or 'delete_' predictably.
Nine tools is an ideal scope for this domain—covering the full video generation lifecycle (create, status check, retrieval, deletion, listing) plus four discovery tools for auxiliary resources (games, memes, music, templates). No bloat, no gaps in the surface area.
Covers the essential CRUD operations and resource discovery well. Minor gap: lacks a 'get_request' singular operation to fetch metadata for a specific request without listing all; agents must use list_requests with filtering or combine get_status/get_shorts to reconstruct request state. No cancel/pause functionality mentioned.
Turn long videos into short, captioned viral clips from your AI assistant. 28 tools, OAuth.
Turn long videos into AI-curated short clips: caption, reframe, thumbnail, schedule, and publish.
Clips your uploads into published Shorts, Reels and TikTok posts, with 48h/7d YouTube receipts.
Clip videos into captioned shorts, add captions, and schedule posts from AI agents.
