What can you do with this server?

This server lets you create and manage personalized video gifts (photos + an original AI-generated song) through any MCP-compatible client. * List Occasions (list_occasions): Retrieve supported occasion types (e.g., birthday, anniversary, wedding, graduation) — the occasion drives the song style and tone. * Check Account (check_account): View your API key status and prepaid credit balance before committing to a render. * Create a Gift (create_gift): Build a personalized video gift by specifying recipient details, occasion, relationship, and up to 30 public photo URLs, plus optional narrative context (memories, story notes, feeling words). Create a draft or trigger a full render (costs one credit; requires consent=true and at least one photo). * Get a Gift (get_gift): Fetch a specific gift's status by ID and retrieve the final film URL once delivered. Use this to poll progress after rendering. * List Gifts (list_gifts): Browse all gifts associated with your API key, sorted newest first, with optional status filtering (e.g., 'delivered') and a configurable result limit (up to 50).

How do I use myvideogift-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@myvideogift-mcp Create a birthday gift for my friend using these photos" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

myvideogift-mcp

by CryptoLibertus

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

My Video Gift — MCP server

Create and deliver personalized video gifts (photos + an original song) from any Model Context Protocol client — Claude Desktop, Cursor, agent frameworks, IDEs.

It wraps the My Video Gift agent API. Renders draw from a prepaid credit balance, so the connecting key must be a live key with credits.

Tools

Tool	What it does	API
`list_occasions`	List supported occasions (drives song + tone)	`GET /occasions`
`check_account`	Key status + prepaid credit balance	`GET /account`
`create_gift`	Create a gift from photos + song, optionally render it	`POST /gifts` → `/photos` → `/render`
`get_gift`	Fetch a gift + (once ready) the film URL	`GET /gifts/{id}`
`list_gifts`	List your gifts, newest first (filter by status)	`GET /gifts`

create_gift will not render unless you pass consent=true (you attest you hold the rights to the photos and the recipient's depiction) and at least one photo_urls entry — the guard runs before any credit is spent.

Related MCP server: Compeller MCP

Configuration

Env var	Required	Default
`MVG_API_KEY`	yes	— (a `mvg_live_…` key from developers.myvideogift.com)
`MVG_API_BASE`	no	`https://myvideogift.com/api/v1`

Install (Claude Desktop, Cursor, …)

Add to your MCP client config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "myvideogift": {
      "command": "npx",
      "args": ["-y", "myvideogift-mcp"],
      "env": { "MVG_API_KEY": "mvg_live_your_key_here" }
    }
  }
}

Install (Claude Code plugin)

This repo is also a Claude Code plugin: the MCP server above plus a create-video-gift skill that walks the agent through the account check → occasion → photos → consent → render flow.

From the community marketplace (once listed):

/plugin marketplace add anthropics/claude-plugins-community
/plugin install myvideogift@claude-community

Or straight from a local checkout:

claude --plugin-dir .

Enabling the plugin prompts for your mvg_live_… API key (stored in the OS keychain, not in settings files) and passes it to the server as MVG_API_KEY.

Local dev

npm install
npm run build
npm test        # offline smoke test — boots the server, asserts the tools
MVG_API_KEY=mvg_live_… npm start

Publishing / listing (needs a human account)

npm: npm publish (public) so npx myvideogift-mcp resolves.
Official MCP registry — published as io.github.CryptoLibertus/myvideogift.
Smithery: connect this repo at https://smithery.ai (uses smithery.yaml).
Glama: auto-indexes public GitHub MCP servers.
mcp.so / PulseMCP: submit this repo's URL via their site.

Available Tools

5 tools

check_accountCheck accountA

Return the API key's account status and prepaid credit balance. Use before rendering to confirm there are enough credits.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that it returns status and balance (read operation), with no side effects implied. Adequate for a zero-parameter tool.

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?

Two sentences, front-loaded with purpose. No wasted words. Efficient and direct.

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?

For a simple tool with no parameters and no output schema, the description provides complete information: what it does and when to use it.

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?

No parameters, so schema coverage is 100% by default. Description adds context about what is returned, meeting baseline for zero parameters.

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?

Description clearly states it returns account status and prepaid credit balance, with specific verb 'Return' and resource 'account status and prepaid credit balance'. It distinguishes from sibling tools which are about gifts and occasions.

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?

Explicitly says 'Use before rendering to confirm there are enough credits', giving clear context for when to use. No when-not-to or alternatives, but sufficient for this simple read tool.

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

create_giftCreate video giftA

Create a personalized video gift from photos + an original song and (optionally) render the film. Rendering spends one prepaid credit and takes a few minutes — poll with get_gift, or watch list_gifts for status 'delivered'. You MUST pass consent=true to render (you attest you hold the rights to the photos and the recipient's depiction).

ParametersJSON Schema

Name	Required	Description
`tier`	No	Film tier. Defaults to 'signature'.
`style`	No	Render style preset. Defaults to 'gift' (unchanged). 'social' biases delivery toward vertical 9:16; 'brand' is for branded gifts.
`memory`	No	A sentence or two the song can lean on.
`render`	No	Render the film now (spends one credit). If false, create a draft only. Defaults to false.
`consent`	No	REQUIRED to render: you attest you hold the rights to these photos and the recipient's depiction.
`occasion`	Yes	Occasion id from list_occasions, e.g. 'anniversary-video'. Drives the song and tone.
`photo_urls`	No	Public image URLs of the recipient (up to 30). Required to render.
`story_note`	No	Extra context for the film's narrative.
`relationship`	Yes	Relationship to the recipient, e.g. 'my wife', 'grandpa', 'our team'.
`feeling_words`	No	Up to 6 tone words, e.g. ['joyful','grateful','proud'].
`recipient_name`	Yes	Who the gift is for, e.g. 'Jamie'.

TDQS

A4.8/5.0

Behavior5/5

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

Despite no annotations, description discloses credit consumption, rendering time, and the need for consent. It also explains how to track delivery via polling or watching list_gifts.

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?

Three concise sentences: purpose, behavioral details, critical consent requirement. No wasted words, front-loaded information.

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?

Covers main workflow and key constraints for a complex multi-parameter tool. Lacks explicit mention of return value or that photo_urls are required for rendering (though schema states it). Still quite comprehensive.

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 description coverage is 100%, so baseline is 3. Description adds value by emphasizing the consent parameter's requirement and clarifying defaults (tier, style, render). Some parameter details are already in 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?

Description clearly states the tool creates a personalized video gift from photos and an original song, with optional rendering. It uses a specific verb and resource, distinguishing it from siblings like get_gift and list_gifts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance on when to render (and spend credit) vs create a draft, with the requirement of consent=true for rendering. Also directs to poll with get_gift or watch list_gifts for status updates.

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

get_giftGet video giftA

Fetch one gift by id — its status and, once delivered, the film_url. Poll this after create_gift with render=true.

ParametersJSON Schema

Name	Required	Description	Default
`gift_id`	Yes	The gift_id returned by create_gift.

TDQS

A4.2/5.0

Behavior3/5

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 that film_url is only returned once delivered and suggests polling, but lacks details on idempotency, error handling, or rate limits.

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?

Two sentences, front-loaded with action and result, no unnecessary words.

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 one parameter, no annotations, and no output schema, the description sufficiently covers what the tool does and when to use it. Minor missing details on error scenarios.

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 100% with one parameter. The description adds value by specifying that the gift_id comes from create_gift, which is beyond the schema's basic description.

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 clearly states the verb 'Fetch', the resource 'one gift by id', and the returned data 'status and film_url'. It distinguishes from siblings by mentioning its use after create_gift.

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?

Explicitly says to poll after create_gift with render=true, which provides clear context. However, it does not explicitly mention when not to use it or alternatives.

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

list_giftsList video giftsA

List this key's gifts, newest first. Filter by status (e.g. 'delivered') to find finished films.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max gifts to return (default 20, max 50).
`status`	No	Optional status filter, e.g. 'delivered'.

TDQS

A4.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses ordering and filtering but omits details on pagination behavior beyond schema-defined limit, or error handling for missing keys. Adequate for a simple read operation.

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?

Two sentences, no redundancy. Front-loaded with main action and ordering. Every sentence serves a purpose.

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 tool simplicity (list with optional filter), no output schema needed. Description covers core behavior. Sibling tools are distinct, so no missing context.

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 already describes both parameters (100% coverage). Description adds value by giving a concrete example for 'status' ('e.g. 'delivered'') and linking it to a use case ('find finished films'), enhancing semantic understanding.

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?

Description clearly states verb 'List', resource 'this key's gifts', and ordering 'newest first'. Distinguishes from siblings like 'get_gift' (single) and 'create_gift' (creation).

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?

Suggests using status filter for specific retrieval (e.g., 'find finished films'), implying context for use. Does not explicitly contrast with other tools but the sibling names provide enough differentiation.

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

list_occasionsList occasionsA

List the supported occasions (anniversary, birthday, wedding, memorial, graduation, …). Use an occasion id when creating a gift; it drives the song and tone.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that the tool lists occasions and that the ID drives song and tone. It does not describe any side effects or special behaviors, but for a read-only list with zero parameters, this is adequate.

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 two sentences, concise and front-loaded with the main purpose. Every sentence adds value.

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 zero parameters, no output schema, and no annotations, the description covers the essential purpose and usage context. It could optionally mention if the list is exhaustive or static, but it is complete enough for its simplicity.

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?

The input schema has zero parameters, so schema description coverage is 100%. The description does not need to add parameter details; the baseline for no parameters is 4.

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 clearly states the tool lists supported occasions, provides examples, and explains the purpose of the occasion ID for creating gifts. It is distinct from sibling tools like list_gifts or create_gift.

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?

The description implies when to use it (before creating a gift to get the occasion ID) but does not explicitly state when not to use it or provide alternatives. The context is clear enough for an agent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.2Jul 11, 2026
- First observedcheck_account
- First observedcreate_gift
- First observedget_gift
- First observedlist_gifts
- First observedlist_occasions

Deploy Server

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

TDQS

A4.4/5.0

Scored 2026-07-11 19:35 across 5 tools

Disambiguation5/5

Each tool addresses a distinct aspect: account status, gift creation, retrieval by ID, listing with filters, and occasion enumeration. No functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (check_account, create_gift, get_gift, list_gifts, list_occasions) with no deviations.

Tool Count5/5

Five tools cover the core workflow (check credits, list occasions, create, retrieve, list) without unnecessary additions. The count is well-scoped.

Completeness4/5

The tool set covers credit checking, creation, retrieval, and listing. Missing are update/delete/cancel operations, but these are not essential for the video gift creation domain.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Video Loom
io.github.Wolflangis
Turn audio or text into a finished AI music video: narrative, multi-provider clips, final cut.
Multimedia Processing AI & Machine Learning Image & Video Processing
2
Compeller A
ai.compeller
Create and track AI music videos and audio-reactive visuals from songs.
AI & Machine Learning Multimedia Processing Image & Video Processing
3021
Autosophia Agent Video A
io.autosophia
Script in, finished 1080p narrated video out. Pay per call in USDC via x402.
Image & Video Processing Multimedia Processing Cryptocurrency
81
Chorus A
com.choruskeepsake
Gathers voice, video and written messages from a group into one book for one person.
Communication Note Taking
141

Related MCP Servers

Short Video Maker MCP
Multimedia Processing Text-to-Speech
gyoridavid
A
license
Not graded
quality
F
maintenance
Creates short videos for TikTok, Instagram Reels, and YouTube Shorts using the Model Context Protocol (MCP) and a REST API.
Updated a year ago (2025-06-21 11:17 UTC)
23 npm
1,341
MIT
Compeller MCPofficial
AI & Machine Learning Multimedia Processing Entertainment & Media
Compellerai
A
license
Not graded
quality
D
maintenance
Enables agents to create AI music videos and audio-reactive visuals from songs through MCP, including style discovery, music search, rendering, webhook registration, and media management.
Updated 4 months ago (2026-05-05 00:29 UTC)
1
MIT
MotionKit MCP Server
Multimedia Processing Image & Video Processing
psanders
F
license
Not graded
quality
B
maintenance
Enables AI agents to validate and render branded videos from structured Video Specifications via the Model Context Protocol. Provides tools for health checks, video validation, and deterministic Remotion rendering.
Updated 6 days ago (2026-09-10 01:05 UTC)
-
lyric-studio
Image & Video Processing Audio Processing
mudon
F
license
Not graded
quality
C
maintenance
Enables AI assistants to create lyric videos by adding images, audio, styled text, and timed lyric lines, then rendering the final MP4.
Updated 22 days ago (2026-08-25 06:18 UTC)
-

My Video Gift — MCP server

Tools

Configuration

Install (Claude Desktop, Cursor, …)

Install (Claude Code plugin)

Local dev

Publishing / listing (needs a human account)

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Compeller MCPofficial