Skip to main content
Glama

Magic Hour

by ai.magichour.mcp
OverviewDiscussionsAdmin

AI Headshot Generator

ai_headshot_generator_create_image

Create an AI headshot. Each headshot costs 50 credits.

MCP guidance:

  • This starts an async image generation job and returns id plus credits_charged immediately. If the user wants the finished result, call the wait_for_image_project helper with the returned id, or poll the matching GET /v1/image-projects/{id} endpoint until status is complete, error, or canceled. Completed projects include downloads with direct URLs. The custom wait helper also returns exact_download_urls separately from expiration metadata.

  • For *_file_path values, prefer an existing Magic Hour file path or a file_path returned by the upload-URL endpoint after the file bytes are uploaded. Direct public media URLs may work when they are stable, fetchable, and return raw file bytes, but hotlinked URLs can fail; when in doubt, use the presigned upload flow first and pass the returned file_path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoGive your image a custom name for easy identification.Ai Headshot - dateTime
styleNo
assetsYesProvide the assets for headshot photo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesUnique ID of the image. Use it with the [Get image Project API](https://docs.magichour.ai/api-reference/image-projects/get-image-details) to fetch status and downloads.
credits_chargedYesThe amount of credits deducted from your account to generate the image. We charge credits right when the request is made. If an error occurred while generating the image(s), credits will be refunded and this field will be updated to include the refund.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / context
      Removed value: -{
-  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
-  "type": "string"
-}
  2. Changed1 schema field changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
+  "type": "string"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover only the safety profile (not read-only, non-destructive, open-world), and the description adds substantial context beyond that: the 50-credit cost per headshot, that execution is async, exactly what is returned immediately (`id`, `credits_charged`), terminal statuses, and that completed projects carry `downloads` URLs. It also warns that hotlinked source URLs may fail. This is rich, decision-relevant behavioral disclosure.

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 core action and cost are front-loaded in one short line, then organized into two clearly labeled bullets covering async handling and file-path sourcing. Every sentence carries information, though the file-path bullet is dense enough to be slightly hard to scan.

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?

For a nested-object, async, 3-parameter tool with an output schema present, the description covers lifecycle, cost, result retrieval, and input sourcing well enough to invoke correctly. It relies on the output schema for return-value structure and on sibling names for tool selection, which is a reasonable division of labor.

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?

Schema coverage is 67%, and the description compensates meaningfully for the asset parameter by explaining that `*_file_path` values should come from an existing Magic Hour file or the upload-URL endpoint, and why (hotlinked URLs can fail). The `name` and `style.prompt` parameters are left to the schema, which documents them adequately (including the recommendation to omit the prompt).

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 opening line 'Create an AI headshot' gives a specific verb and resource, matching the tool name unambiguously. It does not, however, distinguish itself from the crowded set of sibling image generators (ai_image_generator_create_image, ai_face_editor_edit_image, head_swap_create_image), so an agent must infer the boundary from the name alone.

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 MCP guidance explains the async lifecycle clearly: the call returns immediately, and to get a finished result you call `wait_for_image_project` with the returned id or poll `GET /v1/image-projects/{id}` until terminal status. It also gives concrete when-to guidance for file paths (prefer existing Magic Hour paths or presigned uploads over hotlinked URLs). It stops short of saying when this tool should be chosen over the other generator/editor siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Magic Hour toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources