Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@retomagic/mcp generate an image of a serene lake at sunset"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Magicly image & video generation API. Lets any MCP client (Claude Desktop, IDEs, agents) generate media through your Magicly developer API key.
Create an API key at dev.magicly.ai → API Keys.
Add the server to your MCP client. For Claude Desktop
(claude_desktop_config.json):
{
"mcpServers": {
"magicly": {
"command": "npx",
"args": ["-y", "@retomagic/mcp"],
"env": { "MAGICLY_API_KEY": "sk_live_..." }
}
}
}Restart the client. That's it.
Related MCP server: Gemini Image Gen MCP Server
list_models — list available models with id, media type, price ($) and inputs.
generate — generate an image/video: { model, prompt, aspect_ratio?, size?, seconds?, seed?, image? }. Creates a prediction and waits for the result, returning the output URL(s). Pass wait: false to return immediately with an id to poll.
get_prediction — fetch a prediction's status/output by id.
Env | Default | Description |
| – | Required. Your developer API key ( |
|
| API base URL (override for staging). |
Billing is metered in credits (1000 credits = $1) against your organization's balance. See dev.magicly.ai for pricing, keys and usage.
npm install
npm run build # → dist/
MAGICLY_API_KEY=sk_live_... npm startGenerate an image or video with a Magicly model. Creates a prediction and (by default) waits for the result, returning the output URL(s). Use list_models to discover model ids and their inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed for reproducible output. | |
| size | No | Output size as 'WxH' (models that price/size by resolution). | |
| wait | No | Wait for the result (default true). If false, returns immediately with a prediction id to poll. | |
| image | No | Source image for img2img / edit models: a public https URL or a data:image/...;base64,... URI. | |
| model | Yes | Model id, e.g. 'neuro-art'. | |
| prompt | Yes | The text prompt. | |
| seconds | No | Video length in seconds (video models). | |
| aspect_ratio | No | e.g. '1:1', '16:9' (if the model supports it). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool creates a prediction and by default waits for the result, returning output URLs. Also explains the wait parameter behavior. Lacks information on rate limits or idempotency, but sufficient for a generation tool with no annotations.
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?
Two sentences with no filler, front-loaded with the primary action. Every sentence adds meaningful information.
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?
Covers the core workflow (generate, wait, output), references sibling tools for discovery. Lacks details on error handling or model-specific inputs, but the schema and sibling reference compensate.
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 has 100% coverage, so baseline is 3. Description adds value by explaining the overall behavior (creation, waiting, output URLs) and referencing list_models for model selection, which aids understanding of the 'model' param.
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 generates 'an image or video' with a Magicly model, specifying the verb and resource. It differentiates from siblings by referencing list_models for discovery and implying get_prediction for polling.
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 tells when to use list_models to discover model ids and inputs, providing clear guidance on alternatives. Implicitly advises using get_prediction for polling when wait=false.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status and output of a prediction by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The prediction id returned by generate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description correctly indicates a read operation ('Get'), but does not disclose other behaviors like error conditions or id validity.
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?
Single sentence, 11 words, front-loaded with action. No unnecessary 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?
Lacks output schema or description of return format; does not explain what 'current status and output' means structurally. Adequate for simple retrieval but incomplete.
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 describes the 'id' parameter as 'returned by generate', and description adds no extra meaning beyond the schema. Coverage is high, so baseline score applies.
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 the verb 'Get' and resource 'current status and output of a prediction by its id', distinguishing it from sibling tools generate (creates predictions) and list_models (lists available models).
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?
Implied usage after calling generate to retrieve results, but no explicit guidance on when to use vs alternatives 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.
List the available Magicly models with their id, media type, price ($) and supported inputs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 discloses returned fields but lacks details on caching, ordering, or whether it returns all models. Adequate but not comprehensive for a listing tool.
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?
Single sentence, front-loaded with action and resource, no unnecessary words. Highly concise and 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 zero parameters and no output schema, the description explains the purpose and returned fields. It is complete enough for a simple listing tool, though could hint at output format.
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?
No parameters exist in the input schema, so baseline 4 applies. The description does not need to add parameter info.
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 verb 'List' and the resource 'available Magicly models', and specifies the fields returned (id, media type, price, supported inputs). It distinguishes from sibling tools 'generate' and 'get_prediction' by its distinct purpose.
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 implies usage for discovering models, but lacks explicit when-to-use or when-not-to-use guidance. However, given the simple nature, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0generateget_predictionlist_modelsEach tool has a clearly distinct purpose: generating content, checking prediction status, and listing available models. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (generate, get_prediction, list_models), making them predictable and easy to understand.
Three tools is appropriate for the server's scope: model discovery, content generation, and result retrieval. Each tool serves a necessary function without excess or deficiency.
The tool surface covers the full workflow: listing models to know available options, generating content with optional polling, and checking results asynchronously. No obvious gaps for the intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate AI images and videos from any compatible MCP client.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Multi-model AI image and video generator. 14 models behind one OAuth-secured MCP endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Retomagic-work/rtm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
