What can you do with this server?

This server lets you generate and edit AI videos through the Happy Horse MCP server, then track task results. * Generate videos from text prompts * Animate a first-frame image into a video * Generate videos from 1–9 reference images * Edit a source video with optional reference images and audio settings * Choose models, resolutions (720P/1080P), aspect ratios, durations, and watermarking * Query single tasks or batch-query up to 50 tasks * List available models for each action * Supports async generation via task IDs or callback URLs

How do I use Happy Horse MCP Server?

1. Click on "Install 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., "@Happy Horse MCP Server Generate a 720P, 9:16 video of a white horse crossing a snowy ridge at sunrise." 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.

Happy Horse MCP Server

by AceDataCloud

Overview Schema Related Servers Score Discussions

Python

Hybrid

Happy Horse MCP Server

PyPI Python License

Model Context Protocol server for Happy Horse AI video generation and editing through the Ace Data Cloud API.

Capabilities

Text-to-video generation
First-frame image-to-video animation
Reference-to-video generation with 1-9 subject or style images
Video editing with up to 5 reference images
720P and 1080P output
Single and batch task polling
Local stdio and hosted Streamable HTTP/SSE transports
Direct Bearer token and AceDataCloud OAuth authentication

Related MCP server: WanMCP

Install

pip install mcp-happyhorse
export ACEDATACLOUD_API_TOKEN="your-token"
mcp-happyhorse

Get a token from platform.acedata.cloud.

Configure

Claude Desktop

{
  "mcpServers": {
    "happyhorse": {
      "command": "uvx",
      "args": ["mcp-happyhorse"],
      "env": {
        "ACEDATACLOUD_API_TOKEN": "your-token"
      }
    }
  }
}

Hosted MCP

{
  "mcpServers": {
    "happyhorse": {
      "url": "https://happyhorse.mcp.acedata.cloud/mcp",
      "headers": {
        "Authorization": "Bearer your-token"
      }
    }
  }
}

The hosted endpoint also supports OAuth-capable MCP clients.

Tools

Tool	Purpose
`happyhorse_generate_video`	Generate a video from text
`happyhorse_generate_video_from_image`	Animate one first-frame image
`happyhorse_generate_video_from_references`	Generate from 1-9 reference images
`happyhorse_edit_video`	Edit a source video with up to 5 references
`happyhorse_get_task`	Query one task
`happyhorse_get_tasks_batch`	Query multiple tasks
`happyhorse_list_models`	List valid models for each action

Generation tools submit asynchronously when no callback_url is supplied. Keep the returned task_id, wait about 15 seconds, then call happyhorse_get_task until the response contains a final video_url or terminal error.

Models

Action	Models	Default
Text-to-video	`happyhorse-1.0-t2v`, `happyhorse-1.1-t2v`	`happyhorse-1.1-t2v`
Image-to-video	`happyhorse-1.0-i2v`, `happyhorse-1.1-i2v`	`happyhorse-1.1-i2v`
Reference-to-video	`happyhorse-1.0-r2v`, `happyhorse-1.1-r2v`	`happyhorse-1.1-r2v`
Video edit	`happyhorse-1.0-video-edit`	`happyhorse-1.0-video-edit`

Generation duration is 3-15 seconds. Supported resolutions are 720P and 1080P. Text and reference generation support 16:9, 9:16, 1:1, 4:3, and 3:4. Image-to-video follows the input image ratio. Video-edit duration follows the source video.

Example Requests

Ask your MCP client:

Generate a 720P, 9:16 video of a white horse crossing a snowy ridge at sunrise.

Animate https://example.com/horse.jpg with a slow camera push and wind moving the mane.

Edit https://example.com/source.mp4 to preserve the camera motion but apply the costume style from https://example.com/reference.jpg. Keep the original audio.

Environment

Variable	Default	Purpose
`ACEDATACLOUD_API_TOKEN`	none	API token for local stdio mode
`ACEDATACLOUD_API_BASE_URL`	`https://api.acedata.cloud`	API origin
`HAPPYHORSE_REQUEST_TIMEOUT`	`60`	HTTP request timeout in seconds
`MCP_TRANSPORT`	`stdio`	`stdio` or `http`
`MCP_SERVER_URL`	none	Public URL that enables hosted OAuth
`LOG_LEVEL`	`INFO`	Logging level

Development

pip install -e ".[all]"
pytest --cov=core --cov=tools
ruff check .
mypy core tools main.py

Documentation

License

MIT

Available Tools

7 tools

happyhorse_edit_videoB

Edit a source video using text and optional reference images.

ParametersJSON Schema

Name	Required	Description	Default
`seed`	No	Optional reproducibility seed.
`model`	No	Video-edit model. Currently happyhorse-1.0-video-edit.	happyhorse-1.0-video-edit
`ratio`	No	Output aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.	16:9
`prompt`	Yes	Instructions describing the desired changes.
`duration`	No	Output duration in seconds, from 3 through 15.
`video_url`	Yes	Public URL of the source video to edit.
`watermark`	No	Whether to add a Happy Horse watermark.
`image_urls`	No	Optional style or subject reference images, up to five.
`resolution`	No	Output resolution: 720P or 1080P.	1080P
`callback_url`	No	Optional webhook URL. Omit it to receive a task ID for polling.
`audio_setting`	No	Audio policy: auto, or origin to preserve the source audio.	auto

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the burden of behavioral disclosure, but it only names the operation. It does not mention asynchronous task handling, polling, webhook behavior, or any constraints on source video/editing. The schema hints at async behavior through callback_url, but the description itself adds no transparency.

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 a single, front-loaded sentence with no filler or repetition. Every phrase adds meaning: "edit", "source video", "text", and "optional reference images".

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 11 parameters and no annotations, so the description is minimal. The complete parameter names and schemas compensate, as does the presence of an output schema, but the description omits usage and behavioral context. It is functional but not thorough for a video-editing tool with asynchronous implications.

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 descriptions cover 100% of parameters, so the baseline is 3. The description's mention of "text" and "optional reference images" does indirectly map to prompt and image_ulUrls, but it does not add meaningful detail 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 uses a specific verb and resource: "Edit a source video using text and optional reference images." The word "edit" and "source video" directly distinguishes this from the generate_video family of siblings. It also informs the agent of the core input modalities (text and optional reference images).

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 given about when to choose this tool over siblings such as generate_video_from_image or generate_video_from_references. The description only implies editing an existing video; it does not state explicit conditions, alternatives, or when not to use it.

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

happyhorse_generate_videoB

Generate a video from a text prompt with Happy Horse.

ParametersJSON Schema

Name	Required	Description	Default
`seed`	No	Optional reproducibility seed.
`model`	No	Text-to-video model: happyhorse-1.0-t2v or happyhorse-1.1-t2v.	happyhorse-1.1-t2v
`ratio`	No	Output aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.	16:9
`prompt`	Yes	Detailed text-to-video prompt describing subject, motion, camera, lighting, style, and mood.
`duration`	No	Output duration in seconds, from 3 through 15.
`watermark`	No	Whether to add a Happy Horse watermark.
`resolution`	No	Output resolution: 720P or 1080P.	1080P
`callback_url`	No	Optional webhook URL. Omit it to receive a task ID for polling.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, and the description fails to disclose critical behavioral traits such as asynchronous processing, callback usage, or cost implications.

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

Conciseness3/5

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

The description is very short but lacks necessary detail for a complex tool with 8 parameters; it does not earn its place by adding value beyond purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description omits context like task-based polling behavior, making it incomplete for an 8-parameter generative tool.

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%, so baseline is 3. The description adds no additional parameter meaning 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 'Generate' and resource 'video from a text prompt', distinguishing it from siblings like edit, from image, or from references.

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 on when to use this tool vs alternatives, no prerequisites, exclusions, or context provided.

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

happyhorse_generate_video_from_imageA

Animate a first-frame image with Happy Horse.

ParametersJSON Schema

Name	Required	Description	Default
`seed`	No	Optional reproducibility seed.
`model`	No	Image-to-video model: happyhorse-1.0-i2v or happyhorse-1.1-i2v.	happyhorse-1.1-i2v
`ratio`	No	Output aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.	16:9
`prompt`	No	Optional motion and camera instructions for animating the image.
`duration`	No	Output duration in seconds, from 3 through 15.
`image_url`	Yes	Public URL of the image to use as the first frame.
`watermark`	No	Whether to add a Happy Horse watermark.
`resolution`	No	Output resolution: 720P or 1080P.	1080P
`callback_url`	No	Optional webhook URL. Omit it to receive a task ID for polling.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/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 of explaining behavioral traits. It only says 'Animate' and gives no indication that this is likely an asynchronous task returning a task ID, whether an image URL must be publicly accessible, what the output object contains, or cost/side effects. This is a clear gap for a generation 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?

The description is a single, efficient sentence with zero filler. It communicates the core purpose in the fewest possible words, and there is no redundant content to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a high-complexity tool with nine parameters, multiple sibling tools, and likely asynchronous behavior. The description is a single sentence that only states the primary purpose, leaving the agent to infer when to choose this tool over generate_video or generate_video_from_references, and how to handle job submission and polling. The 100% schema coverage and existence of an output schema mitigate missing return-value details but do not compensate for lack of usage and workflow context.

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 all nine parameters already have individual descriptions with defaults, ranges, enums, and guidance. The tool description itself adds nothing new to the parameter semantics, so the baseline 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 uses a specific verb ('Animate') and a specific resource ('first-frame image'), making it clear this is an image-to-video generation tool. The phrase 'first-frame image' differentiates it from sibling tools like generate_video (presumably text-to-video), edit_video, and generate_video_from_references.

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 clearly implies usage: it should be used when you have a first-frame image to animate with Happy Horse. There is no explicit statement about when not to use it or which sibling tool to prefer, but the context of animating a first-frame image is clear enough without exclusions.

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

happyhorse_generate_video_from_referencesB

Generate a video guided by one or more reference images.

ParametersJSON Schema

Name	Required	Description	Default
`seed`	No	Optional reproducibility seed.
`model`	No	Reference model: happyhorse-1.0-r2v or happyhorse-1.1-r2v.	happyhorse-1.1-r2v
`ratio`	No	Output aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.	16:9
`prompt`	Yes	Video prompt. Refer to supplied images as character1, character2, and so on in list order.
`duration`	No	Output duration in seconds, from 3 through 15.
`watermark`	No	Whether to add a Happy Horse watermark.
`image_urls`	Yes	One to nine public reference image URLs.
`resolution`	No	Output resolution: 720P or 1080P.	1080P
`callback_url`	No	Optional webhook URL. Omit it to receive a task ID for polling.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the basic action, lacking information on authentication, rate limits, async behavior, or the effect of references. The one-sentence description is insufficient.

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

Conciseness4/5

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

One concise sentence with no fluff, front-loading the core action. However, given the tool's complexity (9 parameters), a slightly longer description could improve clarity without being wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite a rich schema and output schema, the description does not explain high-level aspects like the generation process, output format, or when to expect results. It is incomplete for a complex video generation tool.

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 coverage is 100% and each parameter has a clear description (e.g., 'Refer to supplied images as character1...'). The tool description adds minimal extra value over the schema, meeting the baseline for high coverage.

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 verb 'generate' and resource 'video guided by reference images', distinguishing it from siblings like 'happyhorse_generate_video' (no references) and 'happyhorse_generate_video_from_image' (likely single image).

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

Usage Guidelines3/5

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

No explicit when or when-not guidance is provided. The description implies use for video generation with multiple references via parameter 'image_urls', but does not mention alternatives or exclusions, such as for single images.

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

happyhorse_get_taskB

Get the status and final video URL for one Happy Horse task.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	Task ID returned by a Happy Horse generation or edit tool.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided. Description does not disclose behavior like whether the task must be completed, return format for pending tasks, or any side effects. Minimal behavioral context.

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?

Single, front-loaded sentence with no waste. Efficiently communicates core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists but description omits context about status progression (e.g., pending vs completed) or when the URL becomes available. Leaves agent uncertain about expected states.

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 coverage is 100% and the description repeats the schema description verbatim, adding no new information. Baseline 3 applies.

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?

Clearly states action (get), objects (status and final video URL), and scope (one Happy Horse task). Distinguishes from the batch sibling by specifying 'one' task.

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

Usage Guidelines3/5

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

Implies use for single task retrieval but lacks explicit when-to-use vs happyhorse_get_tasks_batch. No mention of prerequisites or when not to use.

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

happyhorse_get_tasks_batchB

Get multiple Happy Horse tasks in one request.

ParametersJSON Schema

Name	Required	Description	Default
`task_ids`	Yes	One to fifty Happy Horse task IDs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so the description must carry full burden. It does not disclose behavioral traits such as idempotency, error handling for invalid IDs, or rate limits. The read-only nature is implied but not stated.

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 a single sentence that states the purpose clearly with no wasted words. It is front-loaded and efficiently communicates the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity and the existence of an output schema (not shown), the description is somewhat adequate but lacks details on error behavior, response format, and prerequisites. It covers the basics but leaves gaps.

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 single parameter 'task_ids' is described in the schema as 'One to fifty Happy Horse task IDs'. The description adds no additional meaning beyond the schema, and coverage is 100%, so baseline 3 is appropriate.

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

Purpose4/5

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

The description clearly states 'Get multiple Happy Horse tasks in one request', specifying the verb and resource. It distinguishes from the sibling tool 'happyhorse_get_task' which retrieves a single task, but does not elaborate on what a 'task' is.

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 on when to use this tool vs alternatives like 'happyhorse_get_task' or when not to use it. The description implies efficiency for multiple tasks but lacks explicit context.

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

happyhorse_list_modelsB

List Happy Horse actions, compatible models, and defaults.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits like read-only nature, authentication requirements, or output structure. The existence of an output schema is not mentioned, leaving the agent uninformed about side effects or capabilities.

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

Conciseness4/5

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

The description is a single, front-loaded sentence that efficiently communicates the tool's purpose. However, it may be too minimal, missing opportunities to provide additional context without significant bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no params, output schema exists), the description is insufficient. It does not explain the relevance of listing actions, models, and defaults, nor does it hint at typical usage scenarios like pre-generation setup, leaving the agent without adequate 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?

The tool has no parameters, so schema coverage is 100% trivially. The description does not need to add parameter details, but it could note that no arguments are required, which it implicitly does by omission.

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

Purpose4/5

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

The description clearly states the tool lists 'Happy Horse actions, compatible models, and defaults,' which distinguishes it from sibling tools that focus on video generation and editing. However, it does not define what 'actions' or 'defaults' encompass, leaving some ambiguity.

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 versus alternatives, such as before generating a video to check available models. The description lacks explicit context for invocation.

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. Dates show when Glama detected each change.

2 tool updatesv0.1.1Aug 24, 2026

Changedhappyhorse_edit_video2 fields changed

addedInput schema / properties / duration

Added value: +{
+  "default": 5,
+  "description": "Output duration in seconds, from 3 through 15.",
+  "maximum": 15,
+  "minimum": 3,
+  "title": "Duration",
+  "type": "integer"
+}

addedInput schema / properties / ratio

Added value: +{
+  "default": "16:9",
+  "description": "Output aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.",
+  "enum": [
+    "16:9",
+    "9:16",
+    "1:1",
+    "4:3",
+    "3:4"
+  ],
+  "title": "Ratio",
+  "type": "string"
+}

Changedhappyhorse_generate_video_from_image1 field changed

addedInput schema / properties / ratio

Added value: +{
+  "default": "16:9",
+  "description": "Output aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.",
+  "enum": [
+    "16:9",
+    "9:16",
+    "1:1",
+    "4:3",
+    "3:4"
+  ],
+  "title": "Ratio",
+  "type": "string"
+}

7 tool updatesv0.1.0Jul 13, 2026
- First observedhappyhorse_edit_video
- First observedhappyhorse_generate_video
- First observedhappyhorse_generate_video_from_image
- First observedhappyhorse_generate_video_from_references
- First observedhappyhorse_get_task
- First observedhappyhorse_get_tasks_batch
- First observedhappyhorse_list_models

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct action: listing models, retrieving single or batch tasks, generating from text/image/references, and editing video. The generation variants are clearly separated by source type and input description.

Naming Consistency5/5

All tools follow the same happyhorse_verb_noun naming pattern with snake_case throughout. Variations like generate_video_from_image and generate_video_from_references are logical extensions of the root verb.

Tool Count5/5

Seven tools cover a focused video generation and editing domain without unnecessary extras. This is a well-scoped size that gives agents a clear, manageable set of operations.

Completeness4/5

The main task lifecycle is covered: model discovery, generation with multiple input modes, editing, and status retrieval including batch. Minor gaps include no list-all-tasks or cancel/delete operations, but these are not essential to the core workflow.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.unifically
One API for 100+ AI video, image, music and speech models.
AI & Machine Learning Image & Video Processing Audio Processing
141
Future Video Studio A
video.future
Create and manage cinematic AI video renders through the Future Video Studio Agent API.
AI & Machine Learning Image & Video Processing
82
MaxVideoAI
com.maxvideoai
Plan, compare, price, generate, and recover AI video from compatible MCP clients.
AI & Machine Learning Image & Video Processing
1
VyraOAuth
io.github.kale-eb
Edit video by talking to your AI — search footage, cut timelines, apply effects, add captions.
Multimedia Processing AI & Machine Learning Image & Video Processing
2

Related MCP Servers

KlingMCP
Image & Video Processing AI & Machine Learning
AceDataCloud
A
license
A
quality
B
maintenance
Kling AI video generation with text-to-video, image-to-video, and multiple quality/speed models via AceDataCloud API.
Updated 9 days ago (2026-08-28 10:41 UTC)
10
1
MIT
WanMCP
AI & Machine Learning Image & Video Processing
AceDataCloud
A
license
A
quality
B
maintenance
Wan AI video generation with text-to-video, image-to-video, and multiple quality models via AceDataCloud API.
Updated 9 days ago (2026-08-28 10:40 UTC)
7
1
MIT
Sisif AI MCP Server
Image & Video Processing AI & Machine Learning Multimedia Processing
vtemian
A
license
Not graded
quality
D
maintenance
Enables AI video generation from text prompts, status monitoring, and video management through the Sisif AI Video API.
Updated 8 months ago (2025-12-29 14:14 UTC)
1
MIT
pmind-veo-mcp
AI & Machine Learning Multimedia Processing Image & Video Processing
piotrkandziora
A
license
A
quality
D
maintenance
Enables video generation from text prompts and image-to-video using Google Veo AI models via the Gemini API.
Updated a year ago (2025-08-01 22:05 UTC)
6
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AceDataCloud/HappyHorseMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server