This server enables AI-powered video generation using Hailuo (MiniMax) models via the Model Context Protocol.
Text-to-Video (hailuo_generate_video): Generate AI videos from text prompts describing the scene, motion, style, and mood.
Image-to-Video (hailuo_generate_video_from_image): Animate a reference image into a video using an image URL and descriptive prompt, with optional Director Mode for enhanced creative control.
Check Task Status (hailuo_get_task): Query the status of a video generation task by ID and retrieve the generated video URL once complete.
Batch Task Status (hailuo_get_tasks_batch): Query up to 50 video generation tasks in a single request.
List Models (hailuo_list_models): View all supported video generation models (minimax-t2v, minimax-i2v, minimax-i2v-director) with descriptions and use cases.
List API Actions (hailuo_list_actions): Get a categorized reference of all available Hailuo API actions and their corresponding tools.
A Model Context Protocol (MCP) server for AI video generation using Hailuo (MiniMax) through the AceDataCloud API.
Generate AI videos directly from Claude, VS Code, or any MCP-compatible client.
Text to Video - Create AI-generated videos from text prompts
Image to Video - Generate videos from reference images
Director Mode - Image-to-video with enhanced creative control
Multiple Models - Support for minimax-t2v, minimax-i2v, minimax-i2v-director
Task Tracking - Monitor generation progress and retrieve results
Related MCP server: SoraMCP
Tool | Description |
| Generate AI video from a text prompt using Hailuo (MiniMax). |
| Generate AI video from a reference image using Hailuo (MiniMax). |
| Query the status and result of a video generation task. |
| Query multiple video generation tasks at once. |
| List all available Hailuo models for video generation. |
| List all available Hailuo API actions and corresponding tools. |
Sign up at AceDataCloud Platform
Go to the API documentation page
Click "Acquire" to get your API token
Copy the token for use below
AceDataCloud hosts a managed MCP server — no local installation required.
Endpoint: https://hailuo.mcp.acedata.cloud/mcp
All requests require a Bearer token. Use the API token from Step 1.
Connect directly on Claude.ai with OAuth — no API token needed:
Go to Claude.ai Settings → Integrations → Add More
Enter the server URL: https://hailuo.mcp.acedata.cloud/mcp
Complete the OAuth login flow
Start using the tools in your conversation
Add to your config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"hailuo": {
"type": "streamable-http",
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your MCP config (.cursor/mcp.json or .windsurf/mcp.json):
{
"mcpServers": {
"hailuo": {
"type": "streamable-http",
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your VS Code MCP config (.vscode/mcp.json):
{
"servers": {
"hailuo": {
"type": "streamable-http",
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Or install the Ace Data Cloud MCP extension for VS Code, which registers the hosted MCP servers with one-click setup.
Go to Settings → Tools → AI Assistant → Model Context Protocol (MCP)
Click Add → HTTP
Paste:
{
"mcpServers": {
"hailuo": {
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Claude Code supports MCP servers natively:
claude mcp add hailuo --transport http https://hailuo.mcp.acedata.cloud/mcp \
-h "Authorization: Bearer YOUR_API_TOKEN"Or add to your project's .mcp.json:
{
"mcpServers": {
"hailuo": {
"type": "streamable-http",
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to Cline's MCP settings (.cline/mcp_settings.json):
{
"mcpServers": {
"hailuo": {
"type": "streamable-http",
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your MCP configuration:
{
"mcpServers": {
"hailuo": {
"type": "streamable-http",
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to Roo Code MCP settings:
{
"mcpServers": {
"hailuo": {
"type": "streamable-http",
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to .continue/config.yaml:
mcpServers:
- name: hailuo
type: streamable-http
url: https://hailuo.mcp.acedata.cloud/mcp
headers:
Authorization: "Bearer YOUR_API_TOKEN"Add to Zed's settings (~/.config/zed/settings.json):
{
"language_models": {
"mcp_servers": {
"hailuo": {
"url": "https://hailuo.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}
}# Health check (no auth required)
curl https://hailuo.mcp.acedata.cloud/health
# MCP initialize
curl -X POST https://hailuo.mcp.acedata.cloud/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'If you prefer to run the server on your own machine:
# Install from PyPI
pip install mcp-hailuo
# or
uvx mcp-hailuo
# Set your API token
export ACEDATACLOUD_API_TOKEN="your_token_here"
# Run (stdio mode for Claude Desktop / local clients)
mcp-hailuo
# Run (HTTP mode for remote access)
mcp-hailuo --transport http --port 8000{
"mcpServers": {
"hailuo": {
"command": "uvx",
"args": ["mcp-hailuo"],
"env": {
"ACEDATACLOUD_API_TOKEN": "your_token_here"
}
}
}
}docker pull ghcr.io/acedatacloud/mcp-hailuo:latest
docker run -p 8000:8000 ghcr.io/acedatacloud/mcp-hailuo:latestClients connect with their own Bearer token — the server extracts the token from each request's Authorization header.
Tool | Description |
| Generate video from a text prompt |
| Generate video using a reference image |
Tool | Description |
| Query a single task status |
| Query multiple tasks at once |
Tool | Description |
| List available models |
| List available API actions |
User: Create a video of waves on a beach
Claude: I'll generate a beach wave video for you.
[Calls hailuo_generate_video with prompt="Ocean waves gently crashing on sandy beach, sunset"]User: Animate this image: https://example.com/image.jpg
Claude: I'll create a video from your image.
[Calls hailuo_generate_video_from_image with first_image_url and appropriate prompt]Model | Type | Description | Requires Image |
| Text-to-Video | Generate video from text prompt (default) | No |
| Image-to-Video | Generate video from a reference image | Yes |
| Director Mode | Image-to-video with creative control | Yes |
Variable | Description | Default |
| API token from AceDataCloud | Required |
| API base URL |
|
| OAuth client ID (hosted mode) | — |
| Platform base URL |
|
| Default video model |
|
| Request timeout in seconds |
|
| Logging level |
|
mcp-hailuo --help
Options:
--version Show version
--transport Transport mode: stdio (default) or http
--port Port for HTTP transport (default: 8000)# Clone repository
git clone https://github.com/AceDataCloud/HailuoMCP.git
cd HailuoMCP
# Create virtual environment
python -m venv .venv
source .venv/bin/activate # or `.venv\Scripts\activate` on Windows
# Install with dev dependencies
pip install -e ".[dev,test]"# Run unit tests
pytest
# Run with coverage
pytest --cov=core --cov=tools
# Run integration tests (requires API token)
pytest tests/test_integration.py -m integration# Format code
ruff format .
# Lint code
ruff check .
# Type check
mypy core tools# Install build dependencies
pip install -e ".[release]"
# Build package
python -m build
# Upload to PyPI
twine upload dist/*HailuoMCP/
├── core/ # Core modules
│ ├── __init__.py
│ ├── client.py # HTTP client for Hailuo API
│ ├── config.py # Configuration management
│ ├── exceptions.py # Custom exceptions
│ ├── oauth.py # OAuth 2.1 provider
│ ├── server.py # MCP server initialization
│ ├── types.py # Type definitions
│ └── utils.py # Utility functions
├── tools/ # MCP tool definitions
│ ├── __init__.py
│ ├── video_tools.py # Video generation tools
│ ├── task_tools.py # Task query tools
│ └── info_tools.py # Information tools
├── prompts/ # MCP prompts
│ └── __init__.py # Prompt templates
├── tests/ # Test suite
│ ├── conftest.py
│ └── __init__.py
├── deploy/ # Deployment configs
│ └── production/
│ ├── deployment.yaml
│ ├── ingress.yaml
│ └── service.yaml
├── .env.example # Environment template
├── CHANGELOG.md
├── Dockerfile # Docker image for HTTP mode
├── docker-compose.yaml # Docker Compose config
├── LICENSE
├── main.py # Entry point
├── pyproject.toml # Project configuration
└── README.mdThis server wraps the AceDataCloud Hailuo API:
Hailuo Videos API - Video generation
Hailuo Tasks API - Task queries
Contributions are welcome! Please:
Fork the repository
Create a feature branch (git checkout -b feature/amazing)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing)
Open a Pull Request
MIT License - see LICENSE for details.
Made with love by AceDataCloud
Generate AI video from a text prompt using Hailuo (MiniMax).
This is the simplest way to create video - just describe what you want and Hailuo
will generate a high-quality AI video.
Use this when:
- You want to create a video from a text description
- You don't have reference images
- You want quick text-to-video generation
For using a reference image, use hailuo_generate_video_from_image instead.
Returns:
Task ID and generated video information including URLs and status.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Video generation model. Options: 'minimax-t2v' (text-to-video, default), 'minimax-i2v' (image-to-video, requires first_image_url), 'minimax-i2v-director' (director-mode image-to-video, requires first_image_url). | minimax-t2v |
| prompt | Yes | Description of the video to generate. Be descriptive about the scene, motion, style, and mood. Examples: 'A cat walking through a garden with butterflies', 'Ocean waves crashing on a beach at sunset', 'A futuristic city with flying cars' | |
| callback_url | No | Webhook callback URL for asynchronous notifications. When provided, the API will call this URL when the video is generated. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that the tool generates video and returns a task ID, URLs, and status, but lacks details on async behavior, processing time, cost, rate limits, or content restrictions. The callback parameter is mentioned but not fully explained.
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 brief and well-structured: a one-line summary, followed by usage guidelines, an alternative note, and a return type statement. Every sentence serves a purpose, and information is front-loaded.
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 presence of an output schema and sibling tools, the description covers core purpose, usage context, and alternative. It lacks details on asynchronous behavior, error handling, and operational constraints, but these are partially addressed by the output schema and callback parameter explanation.
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% with good parameter descriptions. The tool description adds little beyond the schema—it repeats 'text prompt' and the sibling reference. With full schema coverage, baseline is 3, and no significant extra semantic value is provided.
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 the tool's action: 'Generate AI video from a text prompt using Hailuo (MiniMax).' It specifies the verb 'generate', the resource 'AI video', and the input source 'text prompt'. It differentiates from sibling tools by explicitly noting the alternative for reference images.
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?
Explicit 'Use this when:' bullets list three specific scenarios: creating video from text, no reference images, and quick generation. It also tells when not to use it and directs to a sibling tool ('For using a reference image, use hailuo_generate_video_from_image instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate AI video from a reference image using Hailuo (MiniMax).
This allows you to create a video based on a reference image. Hailuo will
animate the image content according to your text prompt.
Use this when:
- You have a specific image you want to animate
- You want to create a video based on visual content
- You need image-to-video generation
The first_image_url parameter is required for this tool.
Returns:
Task ID and generated video information including URLs and status.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Video generation model. Options: 'minimax-i2v' (image-to-video, default for this tool), 'minimax-i2v-director' (director-mode image-to-video with more creative control). | minimax-i2v |
| prompt | Yes | Description of the video motion and content. Describe what should happen in the video, how objects should move, what transitions to include. | |
| callback_url | No | Webhook callback URL for asynchronous notifications. When provided, the API will call this URL when the video is generated. | |
| first_image_url | Yes | URL of the reference image for image-to-video generation. The video will be generated based on this image. Required for minimax-i2v and minimax-i2v-director models. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that Hailuo will animate the image content according to the text prompt and returns a task ID and video info. However, it does not mention processing time, image format limitations, or whether the call is synchronous or asynchronous (though callback_url suggests async). Adequate but could provide more operational details.
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 well-organized with clear sections for usage conditions and return values. It is about 10 sentences, which is appropriately sized. It front-loads the main purpose and provides structured bullet points. Slight redundancy in the usage list could be trimmed.
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 has 4 parameters (2 required) and an output schema exists (not provided but referenced), the description covers the essential context: it explains the tool's purpose, required parameter, return structure. It provides sufficient information for an agent to decide to use it, though it could mention model-specific nuances.
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%, so the baseline is 3. The description adds context that 'first_image_url' is required for this tool and explains model options ('minimax-i2v' default, 'minimax-i2v-director' for more control). However, it does not significantly enhance understanding beyond the schema's own descriptions.
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 it generates AI video from a reference image using Hailuo. It explicitly says 'image-to-video generation' and distinguishes from the sibling tool 'hailuo_generate_video' (which is presumably text-to-video) by specifying the required 'first_image_url' parameter.
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 includes 'Use this when:' bullet points listing specific scenarios: having a specific image to animate, creating video based on visual content, needing image-to-video generation. However, it does not explicitly state when not to use this tool or compare it directly to the sibling 'hailuo_generate_video' for text-only prompts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the status and result of a video generation task.
Use this to check if a generation is complete and retrieve the resulting
video URLs and other metadata.
Use this when:
- You want to check if a generation has completed
- You need to retrieve video URLs from a previous generation
- You want to get the full details of a generated video
Task states:
- 'pending': Generation is still in progress
- 'completed': Generation finished successfully
- 'failed': Generation failed (check error message)
Returns:
Task status and generated video information including URLs and status.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task ID returned from a generation request. This is the 'task_id' field from any hailuo_generate_* tool response. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the tool returns status and video URLs, and describes task states. However, it lacks details on response structure, error handling specifics, and any potential rate limits. The provided return summary adds value but is minimal.
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?
Description is very concise: a single purpose line, three use-case bullets, a list of states, and a return summary. No redundant sentences, and key information is front-loaded.
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 polling tool with one parameter and an existing output schema, the description is complete. It explains when to use it, what states to expect, and what the return contains, making it self-sufficient.
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 already fully describes the only parameter (task_id) with clear guidance on where to obtain it. The description does not add additional parameter semantics beyond the schema's coverage, meeting the baseline.
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 it queries the status and result of a video generation task, using specific verb 'query' and resource 'status and result'. It distinguishes from sibling tools like hailuo_get_tasks_batch (which handles multiple tasks) and generation tools.
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?
Explicitly provides three 'Use this when' bullet points covering common scenarios. Lists task states for interpretation. However, it does not explicitly mention when not to use it or suggest alternatives for batch queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query multiple video generation tasks at once.
Efficiently check the status of multiple tasks in a single request.
More efficient than calling hailuo_get_task multiple times.
Use this when:
- You have multiple pending generations to check
- You want to get status of several videos at once
- You're tracking a batch of generations
Returns:
Status and video information for all queried tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| task_ids | Yes | List of task IDs to query. Maximum recommended batch size is 50 tasks. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions efficiency and status/video info return but lacks details on error handling, partial success, or rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently written with bullet points for use cases and a returns line. No extraneous information; every sentence serves a purpose.
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 simple parameter and presence of output schema, description covers core functionality adequately. Missing minor details like error behavior but sufficiently complete for a query 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% and includes max batch size in parameter description. The tool description adds no additional semantic value beyond what schema provides, meeting baseline.
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 it queries multiple video generation tasks at once and explicitly distinguishes from sibling 'hailuo_get_task' by noting efficiency. The action is well-specified.
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?
Provides explicit use cases (multiple pending generations, status of several videos, tracking batch) and implies when not to use (single tasks handled by sibling tool). No misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Hailuo API actions and corresponding tools.
Reference guide for what each action does and which tool to use.
Helpful for understanding the full capabilities of the Hailuo MCP.
Returns:
Categorized list of all actions and their corresponding tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses it returns a categorized list and serves as a reference. It is a read-only operation, and for a simple list tool, the description is sufficiently transparent.
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?
Description is 4 sentences, front-loaded with main purpose. Could be slightly more concise by merging sentences, but overall efficient.
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 simple nature, 0 parameters, and output schema present, description covers the tool's purpose adequately. No major omissions.
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?
Tool has zero parameters and schema coverage is 100%. Baseline 4 applies as description does not need to add parameter details. No param info needed.
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 'List all available Hailuo API actions and corresponding tools.' It effectively uses verb+resource and distinguishes itself from sibling tools (generation, retrieval, model listing) by focusing on listing actions and tools.
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?
Description suggests use for understanding full capabilities, but lacks explicit when-to-use or when-not-to-use guidance relative to siblings. No exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available models for Hailuo video generation.
Shows all available model options with their descriptions and use cases.
Use this to understand which model to choose for your video.
Returns:
Table of all models with their descriptions and use cases.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | 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 describes the tool as listing models and returning a table, implying a read-only, non-destructive operation. This is acceptable but lacks explicit statements about safety or side effects.
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 very concise with two brief paragraphs and a Returns line. It is front-loaded with the core purpose, making it easy to scan. No superfluous text.
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 no parameters, full schema coverage, and an output schema present, the description sufficiently covers the tool's purpose and output. It mentions the returns table and use cases. Could add safety hints, but overall adequate.
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 input schema has zero parameters, so there is nothing to document beyond what the schema already conveys. The description adds no parameter details, but baseline 4 is appropriate since there are no parameters.
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 'List all available models for Hailuo video generation,' identifying the verb (list) and resource (available models). It distinguishes from sibling tools like hailuo_generate_video, which focus on generation, not listing.
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 advises 'Use this to understand which model to choose for your video,' indicating it is a preliminary step before generation. It provides clear context but lacks explicit exclusions 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.
Each tool has a clearly distinct purpose: text-to-video, image-to-video, single task query, batch query, listing actions, and listing models. Descriptions explicitly differentiate between similar tools, leaving no ambiguity.
All tools follow a consistent 'hailuo_verb_noun' pattern with snake_case (e.g., generate_video, get_task). The naming convention is uniform and predictable.
With 6 tools, the set is well-scoped for a video generation service. It covers generation, status checking (single and batch), and reference tools without unnecessary additions.
The tool surface covers the core workflow: text-to-video, image-to-video, task polling (single and batch), and model/action discovery. No obvious gaps given the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Browse 35+ AI video and image models with credit costs, and generate video with an API key.
AI content generation with 50+ models: image, video, TTS, voice cloning, and more.
Generate AI images and videos (Flux, Nano Banana, Kling, Veo, 48+ models), refunds on failure.
One API for 100+ AI video, image, music and speech models.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AceDataCloud/HailuoMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
