Which integrations are available for this server?

Allows generating and managing short-form video ads tailored for Instagram Reels, including scene types, subtitles, and music. Enables creation and scheduling of short-form video ads optimized for TikTok, with customizable templates and voiceover. Supports generating YouTube Shorts ads from text briefs, with options for music mood, subtitles, and automated scheduling.

How do I use @demostudio/mcp-server?

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., "@@demostudio/mcp-server Generate a 30-second Instagram Reel for my SaaS" 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.

@demostudio/mcp-server

by 32bitsret

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

@demostudio/mcp-server

MCP server for DemoStudio — lets any MCP-compatible AI assistant (Claude Code, Cursor, Windsurf, etc.) generate short-form video ads directly from a conversation.

What it does

generate_video — Turn a text brief into a rendered Instagram Reel / TikTok / YouTube Short
get_video_status — Check build progress and get the exported video URL
list_capabilities — Show all 5 scene types and 17 Remotion templates
create_schedule — Set up the Agent to auto-generate videos on a recurring schedule

Related MCP server: autodemo

Requirements

Node.js 18+
A DemoStudio API key — get one at demostudio.xyz/settings

Installation

Claude Code

claude mcp add --transport stdio \
  --env DEMOSTUDIO_API_KEY=your_api_key_here \
  demostudio \
  -- npx -y @demostudio/mcp-server

Cursor / Windsurf

Add to your MCP config file (~/.cursor/mcp.json or ~/.codeium/windsurf/mcp_config.json):

{
  "mcpServers": {
    "demostudio": {
      "command": "npx",
      "args": ["-y", "@demostudio/mcp-server"],
      "env": {
        "DEMOSTUDIO_API_KEY": "your_api_key_here"
      }
    }
  }
}

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "demostudio": {
      "command": "npx",
      "args": ["-y", "@demostudio/mcp-server"],
      "env": {
        "DEMOSTUDIO_API_KEY": "your_api_key_here"
      }
    }
  }
}

Usage examples

Once installed, just talk to your AI assistant naturally:

Generate a 30-second Instagram Reel for my SaaS product.
It's an AI inbox tool called Clearbox. Target: busy founders.
Tone: confident, direct. End with "Try it free at getclearbox.com".
Music: uplifting. Add subtitles.

What Remotion templates does DemoStudio support?

Check the status of project abc-123.

Set up a weekly automated video for my brand.
Product: Kova — project management for remote teams.
URL: https://getkova.com. Calm music. Run every Monday.

Tools reference

`generate_video`

Parameter	Type	Required	Description
`prompt`	string	✓	Full creative brief — product, audience, tone, scenes, CTA
`product_url`	string		URL to crawl for brand colors, logo, description
`music_mood`	`hype` \| `uplifting` \| `calm`		Background music mood
`subtitles`	boolean		Burn subtitles onto voiceover scenes (default: true)
`voice_gender`	`male` \| `female`		Preferred voiceover gender

Returns a project URL to preview and export the video.

`get_video_status`

Parameter	Type	Required	Description
`project_id`	string	✓	Project UUID from `generate_video`

`list_capabilities`

No parameters. Returns all 17 Remotion templates with descriptions.

`create_schedule`

Parameter	Type	Required	Description
`frequency`	`daily` \| `weekly` \| `biweekly` \| `monthly`	✓	How often to generate
`run_day_of_week`	number (0–6)		Day of week (0=Sun). Applies to weekly/biweekly/monthly
`brand_description`	string		Text brief added to the Knowledge Base
`product_url`	string		URL to crawl and add to the Knowledge Base
`music_mood`	`hype` \| `uplifting` \| `calm`		Default music for automated runs

Pricing

DemoStudio is credit-based. New accounts get 500 free credits (enough for ~1 full video). Active accounts receive up to 500 bonus credits every month.

Scene generation: 10 credits
Video export: 400 credits
Automated run: ~700 credits

View pricing →

License

MIT

Maintainer guide — publishing updates

1. Make code changes in `src/index.ts`

2. Bump the version

npm version patch   # 0.1.2 → 0.1.3  (bug fix / small change)
npm version minor   # 0.1.2 → 0.2.0  (new tool or renamed tool)
npm version major   # 0.1.2 → 1.0.0  (breaking change)

3. Publish to npm

npm publish --access public

The prepublishOnly script runs tsc automatically before publishing.

4. Update `server.json` — bump both version fields

{
  "version": "0.1.3",          ← top-level version
  "packages": [{
    "version": "0.1.3"         ← must match npm version
  }]
}

5. Re-authenticate and publish to MCP registry

The registry JWT expires after ~1 hour. Always re-login before publishing.

# Download the publisher binary (if not already on PATH)
curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher

# Login via GitHub device flow
./mcp-publisher login github
# → go to https://github.com/login/device and enter the printed code

# Publish
./mcp-publisher publish server.json

6. Push to GitHub

git add -A
git commit -m "chore: bump to vX.Y.Z — <what changed>"
git push origin main

Notes

server.json $schema URL is versioned — only update it if the registry publishes a new schema version (check https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/CHANGELOG.md)
.mcpregistry_* files are gitignored — they contain auth tokens and must never be committed
The npm token is stored in ~/.npmrc — re-run npm set //registry.npmjs.org/:_authToken <token> if it expires

Available Tools

4 tools

create_scheduleA

Set up the DemoStudio Agent to automatically generate and export a new video on a recurring schedule (daily, weekly, biweekly, or monthly) from a brand Knowledge Base. The Agent varies the hook angle and structure each run to avoid repetition.

ParametersJSON Schema

Name	Required	Description
`frequency`	Yes	How often to generate a new video.
`music_mood`	No	Default music mood for automated runs.
`product_url`	No	Optional product URL to crawl and add to the Knowledge Base. Brand colors and logo will be extracted automatically.
`run_day_of_week`	No	Day of week for the run (0 = Sunday … 6 = Saturday). Only applies to weekly/biweekly/monthly.
`brand_description`	No	Text description of the brand to add to the Knowledge Base as the first entry. Describe the product, audience, tone, and goals.

TDQS

A3.6/5.0

Behavior3/5

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

The description discloses a key behavioral trait: the Agent varies hook angle and structure each run to avoid repetition. However, it does not cover other important aspects such as idempotency, effects on existing schedules, required permissions, or error handling. Since no annotations are provided, the description carries full burden but only partially meets it.

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 concise at two sentences, efficiently covering purpose, frequency options, and a notable behavioral detail. Every sentence adds value with no fluff. Front-loaded with the core action.

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 the tool complexity (5 params, no output schema), the description provides sufficient context for setup but lacks information about return values (e.g., schedule ID) or error conditions. The schema covers parameters well, so the description completes the picture reasonably for its purpose.

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

Parameters3/5

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

All 5 parameters have schema descriptions resulting in 100% coverage. The tool description adds minimal extra meaning beyond the schema (e.g., noting the Knowledge Base as a source). Per the rubric, baseline is 3 when coverage is high, and the description does not significantly augment the parameter 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?

The description clearly states the tool's purpose: to set up an automated recurring video generation and export schedule. It specifies the resource (DemoStudio Agent), verb (set up), and key attributes (frequency options, variation in hook/structure). This clearly distinguishes it from sibling tools like generate_video (one-time) and get_video_status (status check).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool vs alternatives, nor are prerequisites or exclusions mentioned. The sibling context implies scheduling is for recurring generation, but the description does not explicitly state this or advise against using it for one-off tasks.

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

generate_videoA

Generate a short-form demo video (Instagram Reel / TikTok / YouTube Shorts) from a text prompt. DemoStudio writes the script, renders each scene with AI video or motion-graphic templates, adds voiceover and music, and returns a project URL where the user can preview and export. Use this when the user wants to create a promotional video, product demo, or UGC-style ad.

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	Full creative brief. Include: product description, target audience, tone, key features to highlight, CTA, any scene-by-scene instructions, preferred music mood (hype / uplifting / calm), and whether to include subtitles. The richer the brief, the better the output.
`subtitles`	No	Whether to burn subtitles onto voiceover scenes. Default: true.
`music_mood`	No	Background music mood. Defaults to auto-selected based on prompt.
`product_url`	No	Optional. A URL to the product website. DemoStudio will crawl it for brand colors, logo, and description to enrich the video automatically.
`voice_gender`	No	Preferred voiceover gender. Default: auto-selected.

TDQS

A4/5.0

Behavior3/5

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

The description outlines the workflow: writes script, renders scenes, adds voiceover and music, returns a project URL. However, with no annotations provided, it lacks details on authentication, rate limits, or potential side effects, which would enhance transparency. The description is adequate but not thorough.

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 four sentences long, front-loaded with the primary action, and each sentence adds value. It efficiently conveys the tool's purpose, process, and usage guidance without redundancy.

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 the tool's complexity (5 parameters, creative generation) and lack of output schema, the description adequately explains what the tool does and that it returns a project URL for preview and export. It could mention processing time or limitations, but overall it provides sufficient context for an agent.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema's parameter descriptions are already detailed (e.g., prompt includes a full creative brief). The main description does not add significant new information about parameters beyond what the schema provides, so a baseline score of 3 is appropriate.

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 generates short-form demo videos for specific platforms (Instagram Reel/TikTok/YouTube Shorts) from a text prompt. It distinctly differentiates from sibling tools like create_schedule, get_video_status, and list_capabilities by focusing on video 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?

The description explicitly says 'Use this when the user wants to create a promotional video, product demo, or UGC-style ad.' This provides clear context for when to use the tool, though it doesn't mention when not to use it or suggest alternatives.

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

get_video_statusA

Check the status of a video project by its ID. Returns current status, scene build progress, and the final exported video URL once export is complete.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	The project UUID returned by generate_video.

TDQS

A4.2/5.0

Behavior4/5

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

The description discloses the return values (status, scene build progress, URL) but does not mention error handling or states like invalid project_id. Given no annotations, it provides adequate transparency for a 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?

The description is two concise sentences with no extraneous words. Every sentence adds value, making it easy to parse.

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?

The description covers the essential return data and source of the project_id. However, it does not mention that the tool is intended for polling or that progress might be incomplete; still, it is sufficient for a simple status check.

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

Parameters3/5

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

The schema already describes the parameter fully (project_id as a UUID from generate_video). The description adds minimal additional context ('by its ID') and does not enhance understanding beyond the schema.

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

Purpose5/5

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

The description clearly states the verb 'Check' and the resource 'status of a video project by its ID'. It distinguishes from sibling tools like generate_video and create_schedule by focusing on status retrieval.

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 usage after generating a video, but does not explicitly mention when not to use or provide alternatives. The context from sibling tools helps, but it lacks explicit usage context.

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

list_capabilitiesA

List all scene types and Remotion motion-graphic templates available in DemoStudio. Call this before writing a detailed prompt so you can reference the correct scene types and template names. Returns all 5 scene types (cinematic, canvas, slideshow, remotion, video) and all 17 Remotion templates.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. It specifies exact counts (5 scene types, 17 templates) and implies read-only behavior. No contradictions or missing critical behavioral info.

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 concise sentences, purpose stated first, usage guidance and specifics follow. No wasted words.

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?

No missing info for a parameterless listing tool. Description covers purpose, usage context, and return content. Sibling tools are unrelated, so no confusion.

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?

Tool has 0 parameters and schema coverage is 100% (empty schema). Description adds no parameter info, but none is needed. Baseline for 0 params 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 explicitly states it lists 'scene types and Remotion motion-graphic templates', uses specific verb 'List' and resource 'DemoStudio', and clearly distinguishes from sibling tools that create schedules, generate videos, or get status.

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?

Provides explicit when-to-use guidance: 'Call this before writing a detailed prompt so you can reference the correct scene types and template names.' No exclusions or alternatives mentioned, but sibling tools are clearly different in function.

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.

4 tool updatesv0.1.3Jul 12, 2026
- First observedcreate_schedule
- First observedgenerate_video
- First observedget_video_status
- First observedlist_capabilities

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.2/5.0

Scored 2026-07-12 03:45 across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: scheduling recurring videos, generating one-off videos, checking status, and listing capabilities. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (create_schedule, generate_video, get_video_status, list_capabilities).

Tool Count5/5

With 4 tools covering generation, scheduling, status, and capabilities discovery, the count is well-scoped for a video generation server.

Completeness4/5

Covers core workflows (create, schedule, check status, list capabilities). Minor gap: no tool to update or delete schedules, but the surface is sufficient for basic use.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

adsmcp
io.github.Adgentek
MCP-native ad server. Monetize AI chatbots and agents with conversational ads.
Marketing AI & Machine Learning
3
TrezaOAuth
io.github.treza-labs
Build, run, schedule, and publish AI video pipelines to YouTube and TikTok from any MCP client.
AI & Machine Learning Image & Video Processing Payments & Billing
1
mcp-veoOAuth
io.github.AceDataCloud
MCP server for Google Veo AI video generation
Multimedia Processing Image & Video Processing Entertainment & Media
23
mcp-wanOAuth
io.github.AceDataCloud
MCP server for Wan AI video generation
AI & Machine Learning Image & Video Processing
21

Related MCP Servers

agent1st-ads-mcp
Marketing Autonomous Agents App Automation
Nolas-Shadow
A
license
A
quality
F
maintenance
MCP server that lets AI agents launch and manage Meta + TikTok ad campaigns autonomously. 1 call 30 seconds to launch.
Updated 6 months ago (2026-03-23 01:33 UTC)
15
7 npm
3
MIT
autodemo
Browser Automation CI/CD & DevOps Agent Orchestration
praveen-palanisamy
A
license
Not graded
quality
A
maintenance
MCP server that turns any running web app into demo videos, interactive walkthroughs, and marketing captures via one command. Enables AI agents to show their work with regenerated demos on every PR.
Updated 2 months ago (2026-07-06 01:48 UTC)
7 npm
4
MIT
Meta Ads MCP
Marketing Social Media
JavierDaimiel
A
license
Not graded
quality
B
maintenance
A Model Context Protocol server that lets AI assistants run your Meta Ads end to end — launch campaigns, upload creatives, update budgets, and dig into performance through natural conversation. Works across Facebook, Instagram, and other Meta surfaces.
Updated 3 months ago (2026-06-19 10:06 UTC)
Business Source 1.1
Heista MCPofficial
Marketing Entertainment & Media AI & Machine Learning
Heista-co
A
license
Not graded
quality
F
maintenance
Decode any video ad, load brand information, and generate ad scripts from inside MCP-compatible clients like Claude and ChatGPT.
Updated 4 months ago (2026-05-13 01:37 UTC)
MIT

@demostudio/mcp-server

What it does

Requirements

Installation

Claude Code

Cursor / Windsurf

Claude Desktop

Usage examples

Tools reference

generate_video

get_video_status

list_capabilities

create_schedule

Pricing

License

Maintainer guide — publishing updates

1. Make code changes in src/index.ts

2. Bump the version

3. Publish to npm

4. Update server.json — bump both version fields

5. Re-authenticate and publish to MCP registry

6. Push to GitHub

Notes

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Heista MCPofficial

`generate_video`

`get_video_status`

`list_capabilities`

`create_schedule`

1. Make code changes in `src/index.ts`

4. Update `server.json` — bump both version fields