Ssemble AI Clipping 用のMCPサーバーです。あらゆるAIアシスタントからバイラルなショート動画を作成できます。
Claude Desktop、Claude Code、Cursor、VS Code、Windsurf、およびMCP互換クライアントで動作します。
このMCPサーバーを使用すると、AIアシスタントがSsembleのAIクリッピングエンジンを利用して、YouTube動画からショート動画クリップを作成できます。AIは以下のことが可能です：
ショート動画の作成：YouTube URLまたはアップロードされたファイルから作成
Webhookコールバック：処理完了時に通知を受け取る（n8n、Zapier、Makeと連携可能）
アセットの閲覧：キャプションテンプレート、BGM、ゲームプレイオーバーレイ、ミームフック
処理の追跡：進捗状況の確認と完成したクリップの取得
リクエストの管理：履歴の表示、結果の取得、古いリクエストの削除
Related MCP server: clipwise-mcp
有効なサブスクリプションを持つSsembleアカウント
APIキー（Ssembleダッシュボードの「Settings」→「API Keys」から取得）
Node.js >= 18
設定ファイルを編集します：
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"
}
}
}
}保存後、Claude Desktopを再起動してください。
claude mcp add ssemble -- npx @ssemble/mcp-server次に、環境変数を設定します：
export SSEMBLE_API_KEY="sk_ssemble_your_key_here"MCP設定に追加します：
{
"mcpServers": {
"ssemble": {
"command": "npx",
"args": ["@ssemble/mcp-server"],
"env": {
"SSEMBLE_API_KEY": "sk_ssemble_your_key_here"
}
}
}
}ツール | 説明 |
| 動画からAI生成ショートクリップを作成します。リクエストIDを即座に返します。 |
| 処理の進捗（0-100%）と現在のステップを確認します |
| 動画URL、タイトル、バイラルスコアを含む完成したクリップを取得します |
| ページネーションとステータスフィルタリングを使用して、すべてのリクエストを一覧表示します |
| リクエストとその動画を完全に削除します |
| キャプションスタイルのテンプレートを閲覧します |
| BGMトラックを閲覧します |
| ゲームプレイオーバーレイ動画を閲覧します |
| 視聴者の注意を引くミームフッククリップを閲覧します |
動画の処理には5〜30分かかります。2つのワークフローが利用可能です：
create_short — ジョブを送信し、リクエストIDを即座に返します
get_status — いつでも進捗を確認できます（キューイング中 → 処理中 → 完了）
get_shorts — 完了時に生成されたクリップを取得します
webhookUrl を指定して create_short を実行 — コールバックURLと共にジョブを送信します
処理が完了または失敗すると、APIが結果と共にHTTP POSTをURLに送信します
ポーリングは不要 — n8n、Zapier、Make、およびカスタムバックエンド統合に最適です
Webhookペイロードの例：
{
"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
}
]
}
}YouTube動画からショート動画を作成：
"https://youtube.com/watch?v=abc123 からショート動画を作成して。最初の10分間を使い、落ち着いたBGMを付けて"
利用可能なアセットを閲覧：
"キャプションテンプレートをすべて見せて" / "どんなBGMが利用できる？"
進捗を確認：
"動画リクエストのステータスはどうなってる？"
結果を取得：
"リクエスト 507f1f77bcf86cd799439011 のクリップをバイラルスコア順で見せて"
変数 | 必須 | 説明 |
| はい | Ssemble APIキー ( |
| いいえ | APIベースURLの上書き (デフォルト: |
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.
