Magic Hour MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as delete_image_project vs. delete_video_project, and face_swap_photo vs. face_swap_video. However, face_swap_video, face_swap_video_individual, and face_swap_video_youtube could cause confusion due to overlapping video face-swapping functionality, though descriptions help differentiate them.
Naming Consistency5/5
Tool names follow a consistent snake_case pattern with clear verb_noun structures, such as delete_image_project, detect_faces, and get_face_detection_result. There are no deviations in naming conventions across all 12 tools.
Tool Count5/5
With 12 tools, the server is well-scoped for its face-swapping and media processing domain. Each tool serves a specific role, from project management to face detection and lip syncing, without feeling excessive or insufficient.
Completeness4/5
The toolset covers core operations like creation (via face swap tools), retrieval (get status tools), deletion, and processing (detect, lip sync). A minor gap exists in update operations for projects, but agents can work around this by re-creating or managing projects through deletion and re-upload.
Average 3.2/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool deletes but doesn't clarify if this is permanent, reversible, requires specific permissions, or has side effects. For a destructive operation, this leaves critical behavioral traits unaddressed.
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, direct sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential action, making it highly efficient and easy to parse.
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?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion, potential errors, or confirmation requirements. Given the complexity and risk of deletion, more context is needed to guide safe usage.
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 schema description coverage is 100%, with the single parameter 'id' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for adequate but unenhanced coverage.
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 action ('Delete') and resource ('an image project'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'delete_video_project' or explain what distinguishes an 'image project' from other project types, preventing a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'delete_video_project' or 'get_image_project_status'. It lacks context about prerequisites, consequences, or appropriate scenarios for deletion, offering only basic functional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are required, what happens to associated resources, or what the response looks like. This is inadequate for a destructive operation with zero annotation coverage.
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 extremely concise ('Delete a video project.') with zero wasted words. It's front-loaded with the essential action and resource, making it efficient despite its brevity.
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?
For a destructive mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical behavioral aspects like irreversibility, permission requirements, error conditions, or response format. The 100% schema coverage helps with parameters but doesn't compensate for the lack of operational 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?
The schema description coverage is 100%, with the single parameter 'id' clearly documented in the schema as 'The video project ID to delete.' The description doesn't add any additional parameter semantics beyond what the schema already provides, so the baseline score of 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 the action ('Delete') and the resource ('a video project'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from the sibling 'delete_image_project' tool, which performs a similar operation on a different resource type.
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?
The description provides no guidance about when to use this tool versus alternatives. There's no mention of prerequisites (like needing a project ID), when-not-to-use scenarios, or comparison with sibling tools like 'delete_image_project' for different resource types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return of 'face IDs' for face swapping, which adds some context, but fails to cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 concise with two sentences that are front-loaded and to the point, avoiding unnecessary details. However, it could be slightly more structured by explicitly separating purpose from outcomes, but overall, it's efficient with minimal waste.
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 complexity (detection in images/videos), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values beyond 'face IDs', error conditions, or how results are structured, leaving the agent with insufficient context for reliable use.
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 input schema has 100% description coverage, so the schema already documents both parameters thoroughly. The description adds no additional meaning beyond what the schema provides, such as explaining how 'confidence_score' impacts detection accuracy or practical use cases for 'file_url'. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose with a specific verb ('detect') and resource ('faces in an image or video'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_face_detection_result', which might retrieve results rather than perform detection, leaving some ambiguity in sibling relationships.
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?
The description provides no guidance on when to use this tool versus alternatives, such as how it differs from 'get_face_detection_result' or when to choose it over other face-related tools. It mentions that returns can be used for face swapping, but this is more of an outcome hint than usage context, lacking explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the core operation but lacks critical details: it doesn't specify whether this is a read-only or destructive operation, what permissions are needed, rate limits, output format, or error conditions. For a tool that likely modifies images, this is a significant gap.
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 extremely concise with just two sentences that directly state the tool's function and required inputs. Every word earns its place, and the information is front-loaded without unnecessary elaboration.
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?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It covers the basic operation but misses crucial context about behavioral traits, output format, error handling, and differentiation from sibling tools. The agent would lack sufficient information to use this tool effectively.
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 schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by implying the relationship between 'target_image_url' (receives the face) and 'source_face_url' (provides the face), but doesn't provide additional syntax, format details, or constraints.
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's purpose with specific verbs ('swap a face onto a photo') and identifies the resources involved ('target photo' and 'source face image'). However, it doesn't explicitly differentiate from sibling tools like 'face_swap_video', which performs a similar operation on video instead of photos.
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?
The description provides no guidance on when to use this tool versus alternatives like 'face_swap_video' or 'detect_faces'. It states what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral disclosure. It states the action ('sync lip movements') but doesn't explain what the tool does beyond that—e.g., whether it modifies the video in-place, creates a new file, requires specific formats, has rate limits, or handles errors. For a tool with 6 parameters and no annotations, this is a significant gap in 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 extremely concise—two sentences that directly state the tool's purpose and required inputs. Every word earns its place, with no redundant information or fluff, making it easy to parse and front-loaded for quick understanding.
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 complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't cover behavioral aspects, output expectations, or error handling. While the schema handles parameters well, the lack of annotations and output schema means the description should do more to compensate, which it fails to do adequately.
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 schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds minimal value beyond the schema by implying the need for video and audio inputs, but it doesn't provide additional context like parameter interactions or usage examples. With high schema coverage, the baseline score of 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 the tool's purpose: 'Sync lip movements in a video to an audio track.' It specifies the verb ('sync') and resources ('video,' 'audio track'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'face_swap_video' or 'detect_faces,' which are related but distinct video/audio processing functions, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions providing 'a video and audio file' but doesn't specify prerequisites, constraints, or compare it to sibling tools like 'face_swap_video' for similar tasks. This lack of context leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the asynchronous nature ('Returns the project ID to check status'), which is valuable. However, it doesn't address critical aspects like processing time, file format requirements, size limits, authentication needs, rate limits, or what happens if the face detection fails.
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 efficiently structured in two sentences: the first states the core functionality, the second explains the return value and status checking. Every sentence serves a clear purpose with no wasted words, though it could be slightly more front-loaded with key behavioral information.
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?
For a complex video processing tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool actually produces (a modified video file? a processing job?), doesn't mention error handling, and provides minimal guidance on parameter usage despite the schema doing the technical documentation.
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 schema fully documents all 5 parameters. The description adds minimal value beyond the schema - it mentions 'source video' and 'face image' which map to the two required parameters, but doesn't provide additional context about parameter interactions, defaults, or practical usage examples.
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 specific action ('Swap a face onto a video') and identifies the key resources involved ('source video' and 'face image'). It distinguishes this tool from siblings like 'face_swap_photo' (photo vs video) and 'face_swap_video_individual' (individual vs unspecified scope) by focusing on the basic video face-swapping operation.
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?
The description provides no guidance on when to use this tool versus alternatives like 'face_swap_video_individual' or 'face_swap_video_youtube'. It mentions the return value ('project ID to check status') but doesn't explain prerequisites, error conditions, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the core action but omits critical details: whether this is a read-only or destructive operation, authentication requirements, rate limits, processing time, output format, or error conditions. The description is insufficient for a mutation tool with zero annotation coverage.
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 extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place with no redundancy or unnecessary elaboration, making it efficient for quick comprehension.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It fails to explain behavioral traits, return values, or error handling. While the schema covers parameters well, the overall context for safe and effective use is inadequate.
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 schema already documents all 5 parameters thoroughly. The description only mentions 'youtube_url' and 'face_image_url', ignoring the other 3 parameters. It adds minimal value beyond what's in the schema, meeting the baseline for high schema 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?
The description clearly states the specific action ('swap a face onto a YouTube video') and identifies the required resources ('YouTube URL and a face image'). It distinguishes from siblings like 'face_swap_photo' (photos vs. videos) and 'face_swap_video' (generic video vs. YouTube-specific).
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?
The description provides no guidance on when to use this tool versus alternatives like 'face_swap_video' or 'face_swap_video_individual'. It states what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral context. It mentions the return content (face IDs and URLs) but lacks details on error handling, rate limits, authentication needs, or whether it's idempotent. For a read operation with zero annotation coverage, this is inadequate.
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 two concise sentences with zero waste: the first states the purpose, and the second specifies the return values. It's appropriately sized and front-loaded with essential information.
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 no annotations and no output schema, the description is minimal but covers the basic purpose and return values. However, for a tool that likely involves async processing and data retrieval, it lacks context on job states, error conditions, or output format details, making it only adequate.
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%, with the single parameter 'id' documented as 'The face detection job ID'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3.
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 verb ('Get') and resource ('result of a face detection job'), specifying it returns 'detected face IDs and URLs'. It distinguishes from siblings like 'detect_faces' (which initiates detection) and status-checking tools, though it doesn't explicitly name alternatives.
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?
The description implies usage after a detection job is completed (by referencing 'job ID'), but doesn't explicitly state when to use this versus alternatives like 'get_image_project_status' or specify prerequisites. No exclusions or clear alternatives are mentioned.
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?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only nature (implied by 'Check') and output behavior ('Returns status, download URLs when complete'), which is helpful. However, it lacks details on error conditions, rate limits, authentication needs, or whether the operation is idempotent.
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 appropriately sized and front-loaded with the core purpose in the first clause. Both sentences earn their place: the first states what the tool does, and the second specifies the return values. There is zero waste or redundancy.
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?
For a simple status-checking tool with one parameter and no annotations, the description is minimally adequate. It covers the purpose and output, but lacks context about error handling, typical status values, or how it relates to sibling tools. Without an output schema, the description's mention of return values is helpful but could be more detailed.
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 schema already documents the single 'id' parameter. The description adds no additional meaning about the parameter beyond what the schema provides (e.g., format examples, where to obtain the ID). The baseline score of 3 is appropriate when the schema does the heavy lifting.
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's purpose with a specific verb ('Check') and resource ('status of a video project'), and provides examples of project types ('face swap, lip sync, etc'). However, it doesn't explicitly differentiate from its sibling 'get_image_project_status', which appears to serve a similar function for image projects.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a project ID from a creation tool), compare it to sibling tools like 'get_image_project_status', or specify when not to use it (e.g., for checking status of non-video projects).
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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a read operation ('Check'), returns status and download URLs upon completion, and implies it may not return URLs if incomplete. However, it lacks details on error handling, rate limits, or authentication needs, leaving gaps for a tool with no annotation coverage.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds critical behavioral context about returns. Every sentence earns its place with zero waste, making it highly efficient.
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 no annotations, no output schema, and a simple single-parameter input, the description is adequate but incomplete. It covers the basic purpose and return values, but lacks details on error cases, response format beyond URLs, or how statuses are defined, which could hinder agent usage in edge scenarios.
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 input schema has 100% description coverage, with the 'id' parameter documented as 'The image project ID.' The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
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's purpose: 'Check the status of an image project' with specific examples like 'face swap photo, etc.' It uses a specific verb ('Check') and resource ('image project'), but doesn't explicitly differentiate from sibling 'get_video_project_status' beyond the resource type distinction.
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?
The description implies usage context by mentioning 'Returns status, download URLs when complete,' suggesting it's for monitoring project completion. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'get_video_project_status' or other project-related tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions the prerequisite ('detect_faces first') but lacks critical behavioral details: it doesn't specify whether this is a read-only or destructive operation, what permissions are needed, rate limits, output format, or error handling. For a video processing tool with no annotations, this is a significant gap.
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 two sentences with zero waste: the first states the purpose, and the second provides essential usage guidance. It's front-loaded and appropriately sized, with every sentence earning its place by adding critical context.
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 complexity of video face-swapping, no annotations, and no output schema, the description is incomplete. It covers purpose and workflow but misses behavioral traits (e.g., destructive nature, processing time), error cases, and output details. However, it does provide key usage guidance, raising it above minimal viability.
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 schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'face IDs from detect_faces result' for 'original_face', but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.
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 specific action ('swap specific faces in a video') and resource ('video'), distinguishing it from siblings like 'face_swap_photo' (photos) and 'face_swap_video' (likely batch processing). It explicitly mentions using 'detect_faces first to get face IDs', which adds precision about the required workflow.
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?
The description provides explicit guidance on when to use this tool ('Use detect_faces first to get face IDs') and implies alternatives by specifying 'specific faces' (vs. batch processing in 'face_swap_video'). It clearly outlines the prerequisite step, helping the agent understand the proper sequence.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'the file path to use in subsequent API calls,' which adds useful context about the output. However, it lacks details on potential errors, file size limits, authentication needs, or rate limits, leaving gaps in behavioral understanding for a mutation 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 appropriately sized and front-loaded, consisting of two concise sentences that directly state the tool's purpose and outcome. Every sentence earns its place by providing essential information without redundancy or unnecessary details.
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 has one parameter with full schema coverage and no output schema, the description is moderately complete. It explains the purpose and return value, but as a mutation tool with no annotations, it could benefit from more details on behavioral aspects like error handling or prerequisites, making it adequate but with clear 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 schema description coverage is 100%, with the parameter 'file_path' fully documented in the schema as 'Local file path to upload (video, audio, or image).' The description does not add any additional meaning beyond this, such as format specifics or constraints, so it meets the baseline score of 3 where the schema handles the parameter documentation.
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 specific action ('Upload a local file') and the resource ('to Magic Hour'), distinguishing it from sibling tools which focus on deletion, detection, swapping, or status retrieval. It explicitly mentions the purpose 'for use in other tools,' which adds context beyond a basic upload operation.
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 provides clear context for when to use this tool ('for use in other tools'), implying it's a prerequisite step for subsequent operations. However, it does not explicitly state when not to use it or name alternatives, such as whether other tools might handle file uploads differently or if there are limitations on file types beyond what's hinted in the schema.
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:

[![magic-hour-mcp MCP server](https://glama.ai/mcp/servers/andrianthan/magic-hour-mcp/badges/card.svg)](https://glama.ai/mcp/servers/andrianthan/magic-hour-mcp)

Score Badge

Copy to your README.md:

[![magic-hour-mcp MCP server](https://glama.ai/mcp/servers/andrianthan/magic-hour-mcp/badges/score.svg)](https://glama.ai/mcp/servers/andrianthan/magic-hour-mcp)

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/andrianthan/magic-hour-mcp'

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