Skip to main content
Glama
AceDataCloud

Happy Horse MCP Server

by AceDataCloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

HappyHorse by Ace Data Cloud

简体中文安装与首用指南

PyPI Python License

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

Use HappyHorse in Glama

Find the Ace-provided HappyHorse source listing or remote connector. Follow the Glama installation, API Token and first-use guide. Public discovery and a successful personal connection are separate checks; generation uses your Ace account balance.

Related MCP server: WanMCP

HappyHorse in goose

Use the independent HappyHorse by Ace Data Cloud native goose plugin: install and API Token guide · 简体中文. It reuses this MCP server and does not imply goose Marketplace or default-provider inclusion.

Find the HappyHorse integration in the official MCP Registry

Open HappyHorse in the official MCP Registry, expand the matching io.github.AceDataCloud entry, and use its Packages or Remotes installation information in a client that consumes MCP catalogs. This is the HappyHorse integration provided by Ace Data Cloud; it is not an endorsement by the model vendor. The Registry is a directory, not the app that runs a tool.

Search for mcp-happyhorse (or io.github.AceDataCloud/mcp-happyhorse) to locate the exact entry. The official Registry search currently matches server names; spaces in a display title do not create extra search aliases. If your client does not consume the catalog, use the client-specific connection instructions below and check Applications → General application for your token, service permissions, balance and current price. Keep the original task ID when checking asynchronous results.

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

Connect: hosted OAuth, API token, or local stdio

The hosted endpoint is https://happyhorse.mcp.acedata.cloud/mcp. Choose one route for the MCP client:

Route

When to use it

Credential setup

Hosted OAuth

The client supports remote MCP OAuth

Add only the URL, then sign in to AceDataCloud and approve access. No token needs to be pasted into client configuration.

Hosted API token

The client cannot finish OAuth, or you need an explicit integration credential

Send an AceDataCloud API token in the Authorization: Bearer … header. Keep it in a local secret store or environment variable.

Local stdio

The client runs a local MCP process

Install mcp-happyhorse and pass ACEDATACLOUD_API_TOKEN to that process. It still calls the AceDataCloud API.

The hosted service advertises OAuth metadata and Dynamic Client Registration (DCR). DCR registers the client application; it is not an API key. OAuth signs you in and the client sends the resulting Bearer token; it may reuse or create an API credential for the account. Browser sign-in still requires an AceDataCloud account. The hosted service can be metered: review current service documentation and displayed pricing before a real operation. Do not configure both an OAuth login and a fixed Authorization header for the same server.

Hosted OAuth examples

  • Claude and Claude Desktop chat: Add a remote custom connector in Customize → Connectors → Add custom connector, enter https://happyhorse.mcp.acedata.cloud/mcp, select sign-in, and choose Register automatically if Claude asks how to register its OAuth client. Complete consent. Claude Desktop's local claude_desktop_config.json is a separate setup. Claude connector guide.

  • Claude Code: claude mcp add --transport http --scope user happyhorse https://happyhorse.mcp.acedata.cloud/mcp, then claude mcp login happyhorse. Check /mcp. Claude Code MCP guide.

  • Cursor: Add a remote server with only https://happyhorse.mcp.acedata.cloud/mcp. For a project, merge the entry below into <project>/.cursor/mcp.json; for personal use, use ~/.cursor/mcp.json. Cursor MCP guide.

  • VS Code / Copilot: Run MCP: Add Server, select HTTP, enter https://happyhorse.mcp.acedata.cloud/mcp, then finish the browser sign-in. New portable workspace configs use <project>/.mcp.json; the VS Code-specific format below uses <project>/.vscode/mcp.json or the user profile. Check MCP: List Servers. VS Code MCP setup.

  • Codex: codex mcp add happyhorse --url https://happyhorse.mcp.acedata.cloud/mcp, then codex mcp login happyhorse. Its user settings are in ~/.codex/config.toml. Official Codex MCP guide.

Cursor project config (OAuth):

{
  "mcpServers": {
    "happyhorse": {"url": "https://happyhorse.mcp.acedata.cloud/mcp"}
  }
}

VS Code-specific workspace config (OAuth):

{
  "servers": {
    "happyhorse": {"type": "http", "url": "https://happyhorse.mcp.acedata.cloud/mcp"}
  }
}

Hosted API token

  1. Open Ace Data Cloud → Applications. Sign in, or register an account first.

  2. Find General application. If it has not been created, choose Initialize General Application. A general key can use the services available to your account; a dedicated application's key is limited to its service. Check the required service/model access and current pricing.

  3. Copy the API Key from the application card, or open Keys / Manage Keys → Create to create a separate key for this integration. Give it a recognizable name so you can revoke or rotate it independently.

  4. When creating a key, review Expiration Time, Set Usage Limitation, and Allowed APIs. Enable only the restrictions you need, allow the operations you will call, then click Create and copy the token from the key list. Task lookup does not grant permission to submit a generation. Confirm the application's balance can cover your first request; any trial allowance is whatever your account currently displays.

  5. Copy only the token value, without quotation marks, spaces, or Bearer . An API Key / API Token field expects this raw value; only a manually configured HTTP Authorization header needs the Bearer prefix. A platform-... account-management token cannot replace a generation API key.

Copy an application API key or open Manage Keys

Create a separately named key with optional restrictions

Save the key in the client's credential store or the environment variable shown below. Never put it in a prompt, shared workflow, screenshot, or Git commit. If authentication fails, check the full copied value, application/service access, expiration, usage limit, and balance before creating another key.

A fixed Bearer header bypasses OAuth. If the header is invalid, remove it before trying browser sign-in; keep the saved credential private.

For Claude Code, the shell expands the token when you add the server; treat the saved user MCP config as a secret:

export ACEDATACLOUD_API_TOKEN='YOUR_API_TOKEN'
claude mcp add --transport http --scope user happyhorse https://happyhorse.mcp.acedata.cloud/mcp \
  --header "Authorization: Bearer $ACEDATACLOUD_API_TOKEN"

For a Claude Code project config, put a variable reference in <project>/.mcp.json and set that variable in the environment that launches Claude Code:

{
  "mcpServers": {
    "happyhorse": {
      "type": "http",
      "url": "https://happyhorse.mcp.acedata.cloud/mcp",
      "headers": {"Authorization": "Bearer ${ACEDATACLOUD_API_TOKEN}"}
    }
  }
}

Cursor uses a different environment-variable syntax in ~/.cursor/mcp.json or an uncommitted project config:

{
  "mcpServers": {
    "happyhorse": {
      "url": "https://happyhorse.mcp.acedata.cloud/mcp",
      "headers": {"Authorization": "Bearer ${env:ACEDATACLOUD_API_TOKEN}"}
    }
  }
}

In VS Code, run MCP: Open User Configuration and merge this server plus its masked input; ${input:...} is for VS Code's user/workspace format and is not portable to the Agent Host .mcp.json format:

{
  "inputs": [
    {"id": "acedata-happyhorse-token", "type": "promptString", "description": "AceDataCloud API token", "password": true}
  ],
  "servers": {
    "happyhorse": {
      "type": "http",
      "url": "https://happyhorse.mcp.acedata.cloud/mcp",
      "headers": {"Authorization": "Bearer ${input:acedata-happyhorse-token}"}
    }
  }
}

For Cline, use its MCP configuration UI or CLI file ~/.cline/data/settings/cline_mcp_settings.json; its remote transport value is streamableHttp. For JetBrains AI Assistant, add a remote URL from Settings → Tools → AI Assistant → Model Context Protocol (MCP). For Zed, use a context_servers entry with the URL only for OAuth or add a local Bearer header. These clients have different configuration schemas; follow their current UI rather than copying another client's JSON. Cline · JetBrains · Zed.

Local stdio

Install the package and give the local process an API token:

python -m pip install mcp-happyhorse
export ACEDATACLOUD_API_TOKEN='YOUR_API_TOKEN'
mcp-happyhorse

For Claude Desktop local MCP, merge this entry into the file opened by its developer settings (~/Library/Application Support/Claude/claude_desktop_config.json on macOS). uvx requires uv on PATH:

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

Keep this user-level file private. Self-hosted HTTP uses mcp-happyhorse --transport http --port 8000; expose it only with suitable network and TLS controls. Local execution still calls the AceDataCloud API.

Check before using the service

  1. https://happyhorse.mcp.acedata.cloud/health returning {"status":"ok"} checks endpoint reachability only.

  2. Confirm that the MCP client loads tools. happyhorse_list_models is a reference tool; it does not verify downstream API access or balance.

  3. If you need a full API check, call happyhorse_generate_video with your own valid input after reviewing current service documentation and displayed pricing. If the result contains a task ID, call happyhorse_get_task on that same ID until terminal success or failure. Do not resubmit the operation just to check progress.

For 401, check which auth route the client used and whether the token or OAuth session is valid. A 403 may mean an account permission or content moderation failure; read the returned error. Insufficient balance and downstream service failures need their own diagnosis. A listed tool or submitted task does not prove a successful result.

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

Documentation

License

MIT

Cline setup / Cline 图文接入

HappyHorse by Ace Data Cloud — English guide · 完整中文图文步骤. The Cline marketplace submission is pending review as of 2026-10-18; the guide labels the manual fallback separately. / Cline 官方目录投稿仍待审核，手动接入不等于已上架。

Available Tools

7 tools
happyhorse_edit_videoBInspect

Edit a source video using text and optional reference images.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNoOptional reproducibility seed.
modelNoVideo-edit model. Currently happyhorse-1.0-video-edit.happyhorse-1.0-video-edit
ratioNoOutput aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.16:9
promptYesInstructions describing the desired changes.
durationNoOutput duration in seconds, from 3 through 15.
video_urlYesPublic URL of the source video to edit.
watermarkNoWhether to add a Happy Horse watermark.
image_urlsNoOptional style or subject reference images, up to five.
resolutionNoOutput resolution: 720P or 1080P.1080P
callback_urlNoOptional webhook URL. Omit it to receive a task ID for polling.
audio_settingNoAudio policy: auto, or origin to preserve the source audio.auto

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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_videoBInspect

Generate a video from a text prompt with Happy Horse.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNoOptional reproducibility seed.
modelNoText-to-video model: happyhorse-1.0-t2v or happyhorse-1.1-t2v.happyhorse-1.1-t2v
ratioNoOutput aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.16:9
promptYesDetailed text-to-video prompt describing subject, motion, camera, lighting, style, and mood.
durationNoOutput duration in seconds, from 3 through 15.
watermarkNoWhether to add a Happy Horse watermark.
resolutionNoOutput resolution: 720P or 1080P.1080P
callback_urlNoOptional webhook URL. Omit it to receive a task ID for polling.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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_imageAInspect

Animate a first-frame image with Happy Horse.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNoOptional reproducibility seed.
modelNoImage-to-video model: happyhorse-1.0-i2v or happyhorse-1.1-i2v.happyhorse-1.1-i2v
ratioNoOutput aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.16:9
promptNoOptional motion and camera instructions for animating the image.
durationNoOutput duration in seconds, from 3 through 15.
image_urlYesPublic URL of the image to use as the first frame.
watermarkNoWhether to add a Happy Horse watermark.
resolutionNoOutput resolution: 720P or 1080P.1080P
callback_urlNoOptional webhook URL. Omit it to receive a task ID for polling.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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_referencesBInspect

Generate a video guided by one or more reference images.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNoOptional reproducibility seed.
modelNoReference model: happyhorse-1.0-r2v or happyhorse-1.1-r2v.happyhorse-1.1-r2v
ratioNoOutput aspect ratio: 16:9, 9:16, 1:1, 4:3, or 3:4.16:9
promptYesVideo prompt. Refer to supplied images as character1, character2, and so on in list order.
durationNoOutput duration in seconds, from 3 through 15.
watermarkNoWhether to add a Happy Horse watermark.
image_urlsYesOne to nine public reference image URLs.
resolutionNoOutput resolution: 720P or 1080P.1080P
callback_urlNoOptional webhook URL. Omit it to receive a task ID for polling.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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_taskBInspect

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

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesTask ID returned by a Happy Horse generation or edit tool.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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_batchBInspect

Get multiple Happy Horse tasks in one request.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idsYesOne to fifty Happy Horse task IDs.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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_modelsBInspect

List Happy Horse actions, compatible models, and defaults.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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.

  1. 2 tool updatesv0.1.1
    • 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"
+}
  2. 7 tool updatesv0.1.0
    • 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
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

A3.6/5.0

Scored across 7 tools

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

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers