This MCP server provides AI agents with direct access to HappyHorse video generation models on RunAPI, enabling task creation, status polling, and pricing lookups.
edit_video: Edit an existing video using the happyhorse-edit-video model. Accepts a source video URL, optional reference images, audio settings (auto or original), and output resolution (720p or 1080p).
image_to_video: Generate a video from a first-frame image using the happyhorse-image-to-video model. Supports output resolution selection.
text_to_video: Create a video from text using either the happyhorse-character or happyhorse-text-to-video model. Supports aspect ratio (16:9, 9:16, 1:1, 4:3, 3:4), output resolution, and reference images.
get_task: Fetch the current status and result payload for any previously created task by providing its task ID and endpoint.
check_pricing: Look up current pricing for any HappyHorse model and endpoint — no API key required. Covers all 4 model variants across 3 endpoints.
All task creation tools support an optional wait parameter to automatically poll for completion. Compatible with Claude Code, Codex, Cursor, Windsurf, VS Code, and Roo Code.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@runapi.ai/happyhorse-mcp Create a video from this image of a horse."
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.
@runapi.ai/happyhorse-mcp is a focused Model Context Protocol server for the HappyHorse model line on RunAPI.
It gives MCP-compatible assistants direct access to 3 endpoints and 7 model variants without loading the full RunAPI catalog.
Use this per-model server when an agent should stay scoped to HappyHorse. Use @runapi.ai/mcp when one assistant should discover every RunAPI model line.
Related MCP server: GPT Image MCP Server
Add it to Claude Code:
claude mcp add happyhorse -s user -- npx -y @runapi.ai/happyhorse-mcpUse project scope when the server should be shared with a repository:
claude mcp add happyhorse -s project -- npx -y @runapi.ai/happyhorse-mcpCodex, Cursor, Windsurf, VS Code, Roo Code, and other MCP hosts can use the same stdio command:
{
"mcpServers": {
"happyhorse": {
"command": "npx",
"args": ["-y", "@runapi.ai/happyhorse-mcp"]
}
}
}check_pricing works before sign-in. For task creation and status polling, ask your assistant to call the login tool. It opens a browser login and saves credentials to ~/.config/runapi/config.json, the same file used by runapi login.
Headless and CI hosts can still set RUNAPI_API_KEY before starting the MCP host.
Ready-made examples are in examples/ for Claude, Cursor, Windsurf, VS Code, and Roo Code.
Tool | Auth | Purpose |
| Yes | Create a HappyHorse edit video task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Create a HappyHorse image to video task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Create a HappyHorse text to video task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Fetch the current status and latest payload for an existing task. |
| No | Look up current pricing for a HappyHorse model and endpoint. |
HappyHorse covers 7 model variants across 3 endpoints. Each tool accepts the models listed for it:
Tool | Models |
|
|
|
|
|
|
Model availability can change between releases. Use check_pricing or the HappyHorse model page for the current catalog view.
Ask your assistant in natural language; it can inspect pricing, create the task, and return the task id plus output URLs.
Run a HappyHorse edit video task with RunAPI.The assistant can call check_pricing, then edit_video, and return the task id, status, and output URLs.
Create the task but don't wait for it to finish.The assistant calls the create tool with wait: false and returns the task id. Check on it later with get_task.
Check current HappyHorse pricing, then create the task if it matches my request.The assistant calls check_pricing and can link to the HappyHorse model page for the canonical catalog entry.
The server resolves auth in this order:
RUNAPI_API_KEY environment variable, useful for headless and CI hosts
~/.config/runapi/config.json, created by the MCP login tool or runapi login
No key, which still allows check_pricing
The config file is normally managed by login. A pre-provisioned headless config can use:
{
"apiKey": "your_runapi_key"
}Do not commit real API keys.
Resource | URL |
HappyHorse model page | |
npm package | |
GitHub repository | |
RunAPI MCP overview | |
RunAPI docs |
Licensed under the Apache License, Version 2.0.
Look up RunAPI pricing for the happyhorse model line.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model slug. Defaults to the line's primary model. | |
| action | No | Endpoint name. Defaults to the endpoint that offers the model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, nor does it mention response format or error behavior. While 'look up' suggests a safe read, the description lacks deeper context that could be expected from a tool with no 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?
The description is a single, concise sentence that gets straight to the point. It is front-loaded with the verb and resource, and every word earns its place. No redundancy or fluff.
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 pricing lookup with two optional parameters and no output schema, the description is largely sufficient. It could be improved by indicating the type of response (e.g., a list of prices), but it is not critical given the tool's simplicity.
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%, with both parameters (model and action) clearly described in the schema. The description adds no additional parameter information, so it meets the baseline for high schema coverage without extra value beyond the schema.
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 a specific verb ('look up') and resource ('RunAPI pricing') with a clear scope ('happyhorse model line'). It unambiguously distinguishes this tool from sibling generation/editing tools like edit_video and image_to_video.
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 clearly implies usage for retrieving pricing information, providing enough context for when to use it. It does not explicitly state exclusions or mention alternatives, but the purpose is self-evident given the sibling tool set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a HappyHorse task on RunAPI (edit video). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | No | ||
| timeout_ms | No | ||
| callback_url | No | ||
| audio_setting | No | ||
| poll_interval_ms | No | ||
| source_video_url | Yes | ||
| output_resolution | No | ||
| reference_image_urls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It discloses that the tool returns a task id, status, and output URLs, but fails to mention async behavior, auth requirements, rate limits, or error handling.
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, concise and front-loaded with the primary action. However, it could be better structured by separating purpose and return information.
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 the complexity (11 parameters, no output schema, no annotations), the description is severely incomplete. It lacks instructions on required inputs, authentication (likely needed given login sibling), and detailed return format.
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 low (18%), and the tool description adds nothing about parameters. It does not explain the meaning or usage of any of the 11 parameters, leaving the agent without necessary context.
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 clearly states that the tool creates a HappyHorse task for editing video on RunAPI, using a specific verb (Create) and resource (HappyHorse task). It distinguishes from sibling tools like text_to_video by explicitly mentioning 'edit video'.
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 no guidance on when to use this tool versus alternatives (e.g., text_to_video). There is no mention of prerequisites, when not to use it, or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current status and latest result payload for a happyhorse task.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Asynchronous endpoint the task was created on. | |
| task_id | Yes | Task id returned when the task was created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It indicates a read operation but does not disclose potential side effects, authentication requirements, or behavior for missing tasks. Minimal behavioral detail.
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?
Single sentence with no extraneous information. Front-loads the key action and resource. Efficient and to the point.
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 provided, but description mentions 'status and latest result payload' without detailing their structure. Could be more complete for agent decision-making, but acceptable for a simple fetch tool.
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%, so parameters are already described. Description adds no additional semantic context beyond what schema provides. Baseline score of 3 is appropriate.
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 clearly states the verb 'fetch' and the resource 'current status and latest result payload for a happyhorse task'. It distinguishes from sibling tools like edit_video and text_to_video which are about creating/editing tasks, not fetching 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?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites, context, or when not to use it. Simply describes the function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a HappyHorse task on RunAPI (image to video). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | No | ||
| timeout_ms | No | ||
| callback_url | No | ||
| duration_seconds | No | ||
| poll_interval_ms | No | ||
| output_resolution | No | ||
| first_frame_image_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions return values but does not disclose async behavior, waiting/polling semantics (despite a 'wait' parameter and timeout options), potential side effects, or prerequisites. This leaves significant behavioral ambiguity.
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 concise sentence, front-loaded with the key action and result. It is efficient with words, though it sacrifices depth. This is not overly verbose, so it scores well on conciseness.
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?
With 10 parameters, no output schema, and no annotations, this description is insufficient. It does not explain the task lifecycle, parameter usage, or how to configure the request. It provides only a minimal overview, which is inadequate for a tool of this complexity.
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 only 20% (2 of 10 parameters described), and the tool description adds no parameter information. It fails to compensate for the low schema coverage, leaving users without guidance on parameters like prompt, seed, duration_seconds, etc.
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 clearly states the action: 'Create a HappyHorse task on RunAPI (image to video).' It specifies the verb, resource, and scope, and differentiates from sibling text_to_video by emphasizing 'image to video.' It also notes the return value (task id, status, output URLs).
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 context is implied through 'image to video,' suggesting when to use it, but there is no explicit guidance on alternatives or when not to use. It does not mention relative to text_to_video or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate RunAPI by opening a browser PKCE login flow and saving the API key to ~/.config/runapi/config.json.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Re-run browser login when the current credential comes from the local config file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the browser-based flow and file saving, but does not mention potential side effects (e.g., overwriting existing config), required user interaction, or any retry/rate limit behavior.
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, efficient sentence that conveys the key information without extraneous words. Every element contributes to understanding the tool's purpose and mechanism.
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 authentication tool with one optional parameter and no output schema, the description is largely complete. It could mention the need for user interaction (browser popup) but otherwise covers the essential details.
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% for the single parameter 'force', which is well-described in the schema. The tool description adds no further clarification about the parameter 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?
The description clearly identifies the action ('Authenticate RunAPI'), the method ('browser PKCE login flow'), and the outcome ('saving the API key to ~/.config/runapi/config.json'). It distinguishes itself from sibling tools which are unrelated video/pricing operations.
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 login is for authentication but does not explicitly state when to use it (e.g., at session start) or when not to use it. The 'force' parameter hints at re-authentication scenarios, but no alternative tools or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a HappyHorse task on RunAPI (text to video). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | No | ||
| timeout_ms | No | ||
| aspect_ratio | No | ||
| callback_url | No | ||
| duration_seconds | No | ||
| poll_interval_ms | No | ||
| output_resolution | No | ||
| reference_image_urls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It mentions 'Returns a task id, status, and output URLs,' which gives some clue about the asynchronous nature, but it doesn't explain side effects, required auth, costs, or how long the task takes. Thus, it's minimally informative.
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 entire description is one 14-word sentence that front-loads the verb and resource. It's efficient and every word contributes to the core message.
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 the tool's complexity (11 parameters, 0 required, no output schema, no annotations), this high-level description is insufficient. It doesn't explain the task lifecycle, how to specify inputs, what the output URLs represent, or how this relates to get_task. The agent would be left guessing.
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 has 11 parameters with only 18% description coverage, and the tool description does not explain any parameters. It doesn't clarify which model to choose, what prompt format is expected, or what the options mean. The description adds no meaning beyond the bare field names.
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 the specific verb 'Create' and identifies the resource as a 'HappyHorse task on RunAPI' with the scope 'text to video,' which clearly distinguishes it from siblings like image_to_video and edit_video. It also states the return type (task id, status, output URLs).
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 phrase 'text to video' clearly implies the tool is for generating video from text prompts, which provides clear context relative to image_to_video. However, it doesn't explicitly mention alternatives or exclusions, so it falls slightly short of full guidance.
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. Dates show when Glama detected each change.
v0.1.8check_pricing1 field changedInput schema / properties / model / enumPrevious value: -[
- "happyhorse-edit-video",
- "happyhorse-image-to-video",
- "happyhorse-character",
- "happyhorse-text-to-video"
-]New value: +[
+ "happyhorse-edit-video",
+ "happyhorse-1.0-i2v",
+ "happyhorse-image-to-video",
+ "happyhorse-1.0-r2v",
+ "happyhorse-1.0-t2v",
+ "happyhorse-character",
+ "happyhorse-text-to-video"
+]image_to_videotext_to_video1 field changedInput schema / properties / model / enumPrevious value: -[
- "happyhorse-character",
- "happyhorse-text-to-video"
-]New value: +[
+ "happyhorse-1.0-r2v",
+ "happyhorse-1.0-t2v",
+ "happyhorse-character",
+ "happyhorse-text-to-video"
+]v0.1.7edit_video8 fields changedInput schema / properties / callback_urlAdded value: +{
+ "type": "string"
+}Input schema / properties / promptAdded value: +{
+ "type": "string"
+}Input schema / properties / reference_image_urls / itemsAdded value: +{}Input schema / properties / reference_image_urls / maxItemsAdded value: +5Input schema / properties / reference_image_urls / typeAdded value: +"array"Input schema / properties / seedAdded value: +{
+ "type": "number"
+}Input schema / properties / source_video_url / typeAdded value: +"string"Input schema / requiredAdded value: +[
+ "source_video_url"
+]get_task1 field changedInput schema / properties / action / descriptionPrevious value: -"Endpoint the task was created on."New value: +"Asynchronous endpoint the task was created on."image_to_videotext_to_video6 fields changedInput schema / properties / callback_urlAdded value: +{
+ "type": "string"
+}Input schema / properties / duration_secondsAdded value: +{
+ "type": "number"
+}Input schema / properties / promptAdded value: +{
+ "type": "string"
+}Input schema / properties / reference_image_urls / itemsAdded value: +{}Input schema / properties / reference_image_urls / typeAdded value: +"array"Input schema / properties / seedAdded value: +{
+ "type": "number"
+}v0.1.6loginv0.1.0check_pricingedit_videoget_taskimage_to_videotext_to_videoEach tool has a clearly distinct purpose: authentication, three video generation modes, task status retrieval, and pricing lookup. No two tools overlap in functionality.
The naming pattern is mostly verb_noun (e.g., get_task, check_pricing) but the video generation tools break this with image_to_video and text_to_video, while edit_video fits the verb pattern. The mix is still readable and predictable in context.
With 6 tools, the server is well-scoped for video generation and task management. Each tool covers a necessary part of the workflow without unnecessary bloat.
The surface covers login, task creation, status retrieval, and pricing. A task listing or cancellation tool would be a minor addition, but the primary use cases are fully supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run multi-step AI pipelines for video, image, audio and text: upload media, run, poll results.
Create and manage cinematic AI video renders through the Future Video Studio Agent API.
Create AI images and videos, manage projects and credits, and use workspace campaign context.
130+ AI models for image, video, music, and audio — 18 model families, one RunAPI account.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/runapi-ai/happyhorse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
