HailuoMCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.8
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.1/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/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. 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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![HailuoMCP MCP server](https://glama.ai/mcp/servers/AceDataCloud/HailuoMCP/badges/card.svg)](https://glama.ai/mcp/servers/AceDataCloud/HailuoMCP)

Score Badge

Copy to your README.md:

[![HailuoMCP MCP server](https://glama.ai/mcp/servers/AceDataCloud/HailuoMCP/badges/score.svg)](https://glama.ai/mcp/servers/AceDataCloud/HailuoMCP)

Latest Blog Posts

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

MCP directory API

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

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

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